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ABSTRACT 


The  Hellenic  Nav\-  ships  have  a  challengir  ;  mission  which  encompasses  tactical, 
operational  and  administrative  tasks  This  mission  r  "ed  out  by  the  personnel  serving 
onboard  In  order  to  more  effectively  manage  the  p  jjnnel,  an  automated  database 
management  system  is  required  This  system  would  contain  all  personnel  records  and 
other  P'*’ninent  information  Furthermore,  the  system  would  prodi-ce  periodic  '^eports 
required  by  other  commands  concerning  crewmembers,  as  well  as  a  variety  of  oilnr 
reports  designed  by  the  user  to  support  the  daily  activities  onboard 

This  thesis  designs  and  implements  an  automated  database  system  that  can  be  used 
on  the  Hellenic  navy  ships  The  methodology  followed  is  the  standard  systems' 
development  life  cycle  (SDLC).  The  requirements  for  the  system  are  obtained,  and  the 
database  and  application  are  designed  and  implemented.  Paradox  is  used  for  the  database 
management  system  software.  Special  issues  like  training,  secunty,  conversion  and 
maintenance  are  taken  into  consideration. 

The  result  of  this  thesis  is  a  functional  application  named  "SPAS"  (Shipboard 
Personnel  Administration  System)  that  will  fulfill  the  users’  requirements,  keep  track  of 
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L  INTRODUCTION 


A.  OBJECTIVE 

This  thesis  designs  and  implements  a  database  system  for  the  Hellenic  Navy  ships. 
The  purpose  of  the  system  is  to  support  all  the  administrative  activities  of  the  personnel 
assigned  onboard  The  implementation  of  the  database  system  would  greatly  reduce  the 
work  hours  spent  on  specific  administrative  tasks  that  are  instrumental  in  accomplishing 
Hellenic  Navy  ships'  principal  tasks  and  maintaining  an  efficient  operational  level.  The 
database  design  takes  into  consideration  the  Hellenic  Navy  ships'  functional  requirements. 
The  primary  function  of  the  database  system  is  to  maintain  the  records  of  necessary 
personnel  and  other  relevant  information.  From  this  database  standard  reports  are 
generated,  and  ad  hoc  queries  and  reports  are  created. 

B.  BACKGROUND 

In  every  battle  ship  the  personnel  should  be  organized  in  such  a  way  that  the  ship 
can  provide  a  variety  of  functions  and  operate  under  different  situations  in  different 
environments.  These  functions  are  performed  by  the  persons  serving  on  the  ship.  The 
management  of  this  personnel  organization  is  a  difficult  and  time-consuming  job  in  terms 
of  personnel  data  entry,  maintenance  of  manually  kept  forms,  determination  and  allocation 
of  duties  and  handling  personnel  requests  Furthermore,  the  large  volume  of  daily,  weekly 
and  monthly  reports  required  either  for  submission  to  the  higher  command  or  for  the 
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ship's  internal  use,  makes  the  personnel  administration  job  very  difficult  In  addition,  the 
command  needs  help  in  making  decisions  about  subjects  of  an  administrative  nature;  for 
example,  having  people  process  data  in  order  to  propose  a  suggestion  is  a  time  consuming 
task  and  might  result  in  inaccurate  and  unreliable  information. 

The  ship  consists  of  departments  which  are  managed  by  the  department  heads,  and 
divisions  which  are  managed  by  the  division  officers.  In  the  Hellenic  Navy,  only 
commissioned  and  non-commissioned  officers  serve  on  a  permanent  basis  while  seamen 
serve  for  a  short  standard  period  of  time.  Crewmember  changes  are  based  on  annual 
occurrences.  Seamen  changes  are  based  on  the  time  served.  From  time  to  time  projection 
tables  must  be  sent  to  the  Navy  training  centers  for  future  needs  of  seamen  assignments. 
The  new  seamen  must  first  obtain  training  for  special  duties;  then  they  have  to  be 
qualified  by  the  division  officer  or  the  department  head;  finally  they  may  get  some 
additional  training  while  they  serve. 

To  help  the  reader  in  what  follows,  the  following  are  some  brief  explanations  of 
terminology  as  applied  in  the  Hellenic  Navy; 

Port  Duty  Station  is  the  assigned  position  in  which  every  crewmember  has  to  work 
while  in  port. 

Fitness  Evaluation  is  a  compulsory  procedure  for  officers  up  to  the  rank  of 
Lieutenant  and  Petty  Officers  up  to  40  years  old,  in  which  they  must  pass  an  annual 
physical  fimess  test 

Promotion  is  a  promotion  in  rank.  Seamen  do  not  receive  promotions,  only  Officers 
and  Petty  Officers  do.  The  promotion  can  never  exceed  the  following  higher  rank 
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Disciplincay  report  comprises  the  crewmember's  offense,  apology,  and  punishment 
A  record  of  the  date,  nature  of  event,  facts  and  everything  related  to  the  offense  is  kept 

Crew  division  systems  is  how  the  crew  is  divided  to  perform  onboard  activities 
There  are  two  crew  division  systems.  The  first  is  called  "Half  Crew  Division  System" 
under  which  each  crewmember  is  scheduled  to  work  6  hours  and  rest  for  6  hours.  The 
second  work  schedule  is  called  "One  Third  Crew  Division  System"  and  has  shifts  of  4 
hours  on  and  8  hours  off.  The  decision  to  adopt  either  one  of  the  systems  depends  on  the 
type  of  ship’s  operations  being  conducted. 

Leave  designates  the  type  of  leave  given  to  crewmembers  In  addition,  seamen 
serving  onboard  a  ship  have  right  to  the  so-called  "sea  duty  leave". 

On  the  Job  Training  Evaluation  (OJT)  applies  to  Officers,  Petty  Officers  and  seamen 
who  are  all  subject  to  OJT  Evaluation.  The  evaluation  occurs  at  regular  intervals  and  is 
set  by  the  Department  Head  or  the  Division  Officer.  If  a  member  changes  his  position, 
the  OJT  Evaluation  is  automatically  performed. 

A  bandon  Ship  Station  is  the  preassigned  station  in  which  every  crewmember  has 
to  proceed  once  the  order  "Abandon  Ship"  has  been  given 

The  Armed  Security  Group  is  composed  of  an  Officer  as  the  leader  and  several 
Petty  Officers  and  sailors;  it  has  the  predefined  task  of  defending  the  ship  against  terrorist 
attacks  or  intruders. 

Change  in  Command  is  a  change  of  role  or  duty  in  the  Department  or  the  Division 
for  an  Officer  or  a  Petty  Officer. 

Mooring.  Anchoring,  and  Towing  station  are  the  areas  where  all  personnel  are 
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assigned  to  be  while  mooring,  anchoring  or  towing  is  occurring 

Training  is  the  term  that  covers  the  training  received  in  a  school  by  an  Officer, 
Petty  Officer  or  seaman. 

A  ir  controller  is  an  Officer  or  Petty  Officer  whose  duty  is  to  control  all  aircraft 
cooperating  with  the  ship 

Alert  Station  is  the  pre-assigned  position  of  each  crewmember  under  alert 
conditions. 

Replenishment  at  Sea  Station  is  the  station  to  which  a  specially  trained  team,  led 
by  an  officer,  proceeds  when  refueling  at  sea.  The  task  of  the  RAS  team  is  to  take  the 
necessary  actions  until  refueling  is  over. 

XO's  Daily  Report  Division  is  the  division  system  in  which  crewmembers  are 
gathered  during  the  XO's  daily  morning  report. 

C.  METHODOLOGY 

There  are  different  methodologies  for  developing  systems.  The  process  that  will  be 
followed  in  this  thesis  captures  the  essence  of  most  development  methodologies.  The 
fundamental  phases  are; 

•  Definition  phase: 

During  the  definition  phase,  the  tasks  are  to  form  the  working  team,  define 
the  problem,  establish  the  scope,  and  access  feasibility  issues 

•  Requirements  phase 

During  the  requirements  phase,  the  tasks  are  to  create  the  user's  data  model. 


4 


determine  the  update,  display,  and  control  mechanisms,  as  well  as  the  functional 
components  of  the  application,  interview  the  users,  and  use  prototypes  to  help  determine 
user  requirements. 

•  Evaluation  phase 

During  the  evaluation  phase,  the  tasks  are  to  select  the  system's  architecture, 
and  reassess  feasibility  issues. 

•  Design  phase 

During  the  design  phase,  the  tasks  are  to  develop  the  database  design  and  the 
application  design  The  database  design  consists  of  structuring  the  relations,  and 
establishing  the  relationships  among  them.  The  application  design,  deals  with  the  design 
of  the  menus,  reports,  and  forms  as  well  as  to  specify  update,  display,  and  control 
mechanisms. 

•  Implementation  phase 

During  the  implementation  phase,  the  tasks  are  to  construct  the  database,  build 
the  application,  and  install  it. 

This  System's  Development  Life  Cycle  was  utilized  in  the  development  of  the  Shipboard 
Personnel  Administration  System  (SPAS)  of  this  thesis. 

D.  CHAPTER  OUTLINE 

The  thesis  is  organized  as  follows: 

Chapter  II  is  a  general  description  of  the  database  development  process  It  reviews 
database  concepts,  and  describes  the  database  development  phases.  These  phases,  the 
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requirements  analysis  and  specification,  the  design,  and  the  implementation,  are  detailed 
in  the  following  chapters. 

Chapter  III  is  the  requirements  analysis  of  the  system.  The  operating  environment 
IS  studied  by  means  of  the  user's  descriptive  list  of  requirements  for  the  system's 
functionality,  data  manipulation  and  production  of  specific  information  The  requirements 
and  accompanied  entity-relationship  data  flow  diagrams  are  provided.  The  chapter 
concludes  with  a  description  of  the  requirements  specifications  as  they  pertain  to  data, 
hardware  and  software  issues. 

Chapter  IV  describes  the  design  process  followed  in  developing  the  Shipboard 
Personnel  Administration  System  (  SPAS  ).  The  data  and  process  models  developed  in 
the  previous  chapters  are  transformed  into  a  relational  and  application  design,  respectively. 
The  last  section  provides  commentary  about  the  data  dictionary  and  its  benefits  to  the 
database  system  design. 

Chapter  V  is  a  discussion  of  the  final  phases  involved  in  developing  the  database 
system.  These  phases  are  the  implementation  portion  of  the  data  and  process  design  and 
they  include  programming  and  planning  for  the  system's  implementation. 

Chapter  VI  deals  with  other  important  issues  in  developing  the  system  such  as 
testing,  database  security,  personnel  training,  system  conversion,  maintenance  and  future 
upgrades. 

Chapter  VII  is  the  concluding  chapter  It  provides  a  short  summary  of  the  thesis 
and  addresses  future  enhancements  to  the  system  developed  Also  included  are  lessons 
learned  in  developing  the  system 


6 


Appendices  A  through  1  supplement  the  previously  described  text  The  appendice'- 
are  Object  Diagrams.  Data  Dictionary,  Data  Flow  Diagrams.  Relational  Schema. 
Application  Menus.  Application  Input  Forms.  Application  Repons.  System  s  Program  and 
Code  and  Procedures  for  installing  and  operating  SPAS,  respectively 
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In  this  chapter  we  will  discuss  basic  database  concepts  as  'veil  as  the  database 
development  methodologs  Each  step  of  the  ss  stem  s  development  methodologs  is 
described  in  some  detail 

A.  DATABASE  CX)NCEPTS 

The  term  database  is  subject  to  many  different  interpretations  It  has  been  used  to 
refer  to  everything  from  a  collection  of  index  cards  to  the  volumes  of  data  that  a 
government  collects  about  its  citizens  In  the  following  we  will  use  this  term  with  a 
specific  meaning:  A  database  is  a  self-describing  collection  of  integrated  records. 

1.  A  Database  is  Self-Describing 

In  addition  to  the  user's  source  data,  a  database  contains  a  description  of  its 
own  structure.  This  description  is  called  the  data  dictionary,  and  makes  program/data 
independence  possible.  In  that  way,  by  examining  the  database  itself,  it's  easy  to 
determine  its  structure  and  its  components;  no  external  documentation  of  file  and  record 
formats  is  needed.  Furthermore,  when  changing  data  in  the  database,  we  only  need  to 
make  corresponding  changes  to  the  data  dictionary 

2.  A  Database  is  a  Collection  of  Integrated  Records 

As  shown  in  figure  1,  a  database  is  more  than  a  collection  of  files.  It  includes 
source  data,  a  description  of  the  database  structure  (data  dictionary),  and  a  description  of 
the  relationships  among  the  records  of  the  files  (overhead  data).  The  main  different 
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between  a  database  and  a  file  processing  ssstem  is  that  a  database  is  able  to  store  these 
relationships 


bytes 

bits  >  or 

characters 


flies 

+ 

data 

fields  y  records  y  dictionary 

♦ 

overhead 

data 


database 


Figure  1 :  Hierarchy  of  data  elements  in  database  processing 

3.  Components  of  a  Database  Processing  System 

A  database  processing  system  has  five  components  as  shown  in  figure  2. 


Bridge 


Figure  2:  Components  of  a  database  processing  system 


These  are  hardware,  programs,  data,  procedures  and  people.  The  most  important 
components  are  the  people  and  the  data.  The  data  contain  all  the  useful  information  that 
people  need  to  perform  their  tasks  and  complete  their  activities. 
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B.  DATABASE  DEVELOPMENT  METHODOLOGY 

The  database  development  methodology  described  here  consists  of  four  phases 
definition,  requirements,  evaluation,  and  design  Each  phase  consists  of  a  number  of 
tasks 

During  the  definition  phase  the  tasks  are  to  form  the  working  team,  define  the 
problem,  establish  the  scope,  and  access  feasibility  issues 

During  the  requirements  phase,  the  tasks  are  to  create  the  user's  data  model,  as  well 
as  the  functional  components  of  the  application.  This  is  accomplished  by  interviewing 
the  users,  and  using  prototypes  to  help  determine  user  requirements 

During  the  evaluation  phase,  the  tasks  are  to  select  the  system's  architecture,  and 
reassess  feasibility  issues. 

During  the  design  phase,  the  tasks  are  to  develop  the  database  design  and  the 
application  design.  The  database  design  consists  of  structunng  the  relations,  and  the 
establishing  relationships  among  them  The  application  design,  deals  with  the  design  of 
the  menus,  reports,  and  firms 

Dunng  the  implementation  phase,  the  tasks  are  to  construct  the  database,  build  the 
application,  and  install  it. 

The  requirements,  design,  and  implementation  are  detailed  in  the  following  sections 

C.  REQUIREMENTS  ANALYSIS  /  SPECIFICATIONS 

Accurately  obtaining  the  system's  information  requirements  from  the  potential  users 
is  essential.  No  system  can  be  designed  without  first  understanding  the  current  process 
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intended  fo'-  improvement  After  the  system's  definition  and  primary  analysis  phtise, 
where  the  general  goals  of  the  system  are  determined,  the  requirements  phase  follows 
The  purpose  of  this  phase  is  to  determine,  as  specifically  as  possible,  what  the  system 
must  do  There  are  two  tasks  in  this  phase; 

•  develop  a  user's  data  model 

•  determine  the  functional  components  of  each  application  that  will  use  the 
database 

1.  Data  Requirements 

During  the  data  requirements  phase,  the  major  goals  are  to  build  a  data  model 
that  documents  the  "things"  that  are  to  be  represented  in  the  database,  to  determine  the 
characteristics  of  those  "things"  that  need  to  be  stored  and  to  determine  the  relationships 
among  them  The  user's  data  model  describes  the  objects  that  must  be  stored  in  the 
database,  along  with  their  structure  and  the  relationships  that  they  have  with  one  another 
The  output  of  the  data  requirements  phase  is  a  statement  of  requirements.  This  statement 
can  take  a  variety  of  forms;  a  verbal  description;  an  entity-relationship  and  objects 
diagrams,  one  or  more  prototypes;  or  any  combination  of  the  above. 

The  "things"  that  are  represented  in  the  database  are  referred  to  as  either  entities  or 
semantic  objects  (in  some  cases  just  objects)  depending  on  the  modeling  technique  that 
the  designer  follows  In  this  thesis  the  semantic  object  model  will  be  followed 

A  semantic  object  is  a  named  collection  of  properties  that  sufficiently  describes  a 
distinct  identity.  Semantic  object  diagrams  assist  in  the  system  analysis  as  well  as  the 
design  phase.  Some  of  the  charactenstics  of  semantic  objects  are. 
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•  the  semantic  objects  are  grouped  into  classes;  each  class  has  a  distinctive 
name;  classes  are  shov/n  in  capital  letters 

•  an  object  is  a  collection  of  properties  with  a  sufficient  description 

•  objects  represent  distinct  identities 

•  the  identities  that  the  objects  represent  may  or  may  not  have  physical  existence 
Objects  have  properties  that  define  their  characteristics.  These  properties  can  be 

simple  property,  composite  of  a  group  of  properties,  or  another  object.  An  object  can 
have  single  or  multiple  values.  In  a  semantic  object  diagram,  objects  are  shown  in  boxes, 
their  name  appears  beneath  or  above  the  rectangle  and  properties  are  written  inside  the 
rectangle.  The  "MV"  symbol  next  to  a  property  declares  that  this  property  can  have 
multiple  values.  The  non-object  properties  have  scalar  values  while  the  object  properties 
are  separate  objects  by  themselves.  Figure  3  shows  a  sample  object. 


Property  1 

Property  2  MV 


Property  3 


Property 


MV 


Figure  3:  Sample  Object 
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A  property  can  take  its  value  from  a  set  of  possible  values,  this  set  is  called  th? 
domain  of  the  property  The  domain  gives  both  the  physical  and  the  semantic  descnption 
The  physical  descnption  indicates  the  type  of  data,  the  length  of  the  property  and 
probably  some  restnctions  or  constraints  that  may  apply  to  the  property  The  semantic 
descnption  describes  the  function  or  purpose  of  the  property 
There  are  six  categories  of  objects; 

a.  Simple  Object 

A  simple  object  contains  only  single-valued,  nonobject  properties. 

b.  Composite  Object 

A  composite  object  contains  one  or  more  nonobject  multivalued 

properties. 

c  Compound  Object 

A  compound  object  contains  at  least  one  object  property. 

d.  Association  Object 

An  association  object  is  an  object  that  relates  two  or  more  objects 
together  and  stores  data  that  is  peculiar  to  their  relationship. 

e.  Hybrid  Object 

Hybrid  objects  are  combinations  of  objects  of  other  types.  Most 
frequently,  hybrid  objects  involve  the  combination  of  a  compound  and  a  composite  object 
in  which  the  object  property  occurs  in  a  composite  group. 
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f.  Generalization  and  Subtype  Objects 

Generalization  and  subtype  objects  are  used  to  model  generalization 
hierarchies.  The  generalization  objects  contain  the  genenc  description  and  indicate  all 
possible  alternatives  for  the  object  property,  while  the  subtype  objects  inherit  the 
properties  from  the  generalization  objects. 

The  process  for  developing  semantic  objects  can  be  done  in  either  a  top-down  or 
bottom-up  fashion  With  the  bottom-up  approach,  developers  examine  the  application 
interface  (primarily,  reports  and  screen  displays)  and  work  backwards  to  derive  the  object 
structure  With  the  top-down  design,  the  developer  starts  with  the  general  idea  of  the 
goals  of  the  application,  involves  the  user  in  the  development  team  and  tries  to  determine, 
based  on  the  nature  of  the  objects  and  the  application  goals,  what  the  properties  are  and 
how  they  are  going  to  be  stored  in  the  database  The  top-down  approach  requires  more 
experienced  developers  and  is  nsky  There  is  a  significant  chance  that  the  imagination 
of  even  skilled  database  designers  will  be  insufficient  and  that  important  properties  or 
objects  will  be  left  out 

Probably  the  best  approach  is  the  combination  of  both  the  top-down  and  bottom-up 
design  The  best  and  the  recommended  way  to  proceed  is  to  have  in  mind  the 
application's  conceptual  idea,  know  the  desired  goals  and  the  systems  functionality, 
involve  the  user  in  the  development  phase  and  start  work  having  the  reports  and  the  user's 
favonte  interface  "handy".  Keep  in  mind  that  "Data  Modeling  is  an  Artistic  Process" 
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2.  Data  Dictionaiy 

A  data  dictionary  or  project  dictionary  as  it  is  sometimes  called,  is  a  catalog 
of  requirements  and  specifications  for  a  new  information  system  (Witten.  1989,  p  331) 
It  provides  definitions  of  all  the  data  items  in  the  database  During  the  definition  phase, 
the  analysts  try  to  capture  and  store  the  data  in  the  system,  and  find  the  inputs  and 
outputs  that  the  system  will  generate.  These  are  represented  with  pictorial  models  such 
as  data  flow  diagrams,  relation  diagrams,  entities,  data  stores  etc  The  data  dictionary 
expands  this  pictorial  model  and  as  a  system  analysis  tool,  captures  the  detailed 
requirements  for  every  input,  output  and  data  store.  The  suggested  approach  for  building 
the  data  dictionary  should  be  in  terms  of  *‘what"  data  are  handled  and  not  in  terms  of 
"how  "  data  are  presented  or  formatted. 

3.  Process  Requirements 

All  systems  process  data  to  produce  information  and  maintain  stored  data.  These 
requirements  should  be  logically  modeled.  In  order  to  implement  processes  as  programs, 
a  process  model  is  needed.  A  process  model  is  a  picture  of  the  flow  of  data  through  the 
system  and  the  processing  that  must  be  performed  on  that  data.  These  processes  interact 
or  interface  with  one  another.  These  interactions  take  the  form  of  data  flows  between 
processes  and  is  the  reason  that  they  are  sometimes  called  data  flow  models  One  of  the 
most  popular  system  modeling  tools  for  capturing  process  requirements  is  the  data  flow 
diagrams  (DFDs). 

It  should  be  emphasized  that  data  flow  diagrams  are  very  different  from  flow  charts, 
in  the  following  ways: 
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•  Processes  on  a  DFD  can  operate  in  parallel;  several  processes  may  be  working 
simultaneously.  This  is  a  key  advantage  over  flowcharts,  which  tend  to  show 
only  sequences  of  processes 

•  DFDs  show  the  flow  of  data  through  a  system  unlike  flowcharts  that  show 
steps  in  an  algorithm 

•  DFDs  can  show  processes  that  have  dramatically  different  timing  while 
flowcharts  can't 

The  following  describes  the  basic  components  of  a  dataflow  diagram. 

a.  Internal  or  External  Entity 

Every  system  has  a  boundary.  This  boundary  is  defined  by  the  internal 
or  external  entities  which  provide  the  net  input  to  the  system  and  receive  the  net  output 
from  the  system.  The  entities  sometimes  are  called  sources  or  destinations  depending  on 
whetner  they  are  inputs  to  the  system  or  outputs  from  the  system.  Names  and  titles  can 
be  used  to  describe  the  label  of  the  entities.  Entities  never  interact  directly  with  data 
stores,  and  relationships  between  entities  are  not  modeled. 

b.  Process 

The  emphasis  on  any  DFD  is  given  to  the  processes,  sometimes  called 
activities.  Processes  transform  inputs  into  outputs  and  transform  the  structure  of  data  into 
information  contained  in  the  data.  The  logic  or  the  procedure  that  a  process  uses  to 
complete  its  task  is  not  shown.  Processes  are  titled  by  using  verb-clause  form 
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c.  Data  Store 


Data  stores,  as  the  name  implies,  shows  the  logical  storage  of  the 
information.  Data  flow  from  a  data  store  represents  the  "usage"  of  data.  This  is  the  place 
where  the  data  are  stored  after  a  process,  or  from  where  they  are  retrieved  to  be 
processed. 

d.  Data  Flow 

The  data  flows  represent  inputs  or  outputs  that  move  from  or  to  processes 
and  from  or  to  data  stores.  They  are  titled  by  a  noun-clause  form.  Data  transferred 
together  must  be  shown  as  a  single  data  flow  no  matter  how  many  documents  are 
physically  involved. 

There  are  two  different  but  equivalent  symbol  sets  for  DFDs;  the  Gane-Sarson 
symbols  and  the  DeMacro-Yourdon  set.  The  use  of  these  sets  is  based  on  which  one  the 
user  feels  more  comfortable  with.  Figure  4,  introduces  the  two  different  sets  of  models 
and  shows  how  the  entities,  the  data  flows,  the  processes  and  the  data  stores  are 
represented  in  each  of  the  models. 
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e.  Leveling  of  DFDs 

When  studying,  analyzing  and  designing  a  system,  it  is  good  to  have  a 
genenc  pictorial  outline  of  what  the  system  does  or  will  do  when  it  is  implemented.  This 
pictorial  outline  which  is  called  "Decomposition  Diagram",  also  called  "hierarchy  chart", 
shows  the  top-down  functional  decomposition  or  structure  of  a  system.  Decomposition 
diagrams  also  provide  an  outline  for  drawing  the  DFDs.  Only  the  processes  are  presented 
on  decomposition  diagrams  and  they  are  connected  to  form  a  treelike  structure.  Process 
names  conform  with  the  ones  that  are  referred  to  in  the  DFDs.  The  top  process  is  called 
the  root;  it  is  exploded  or  factored  out  to  subsystems,  functions  or  tasks.  It  defines  the 
scope  and  boundary  of  the  system  to  be  developed. 

D.  DATABASE  DESIGN 

The  goal  of  the  design  phase  is  to  develop  a  blueprint  of  all  five  components, 
shown  in  figure  2,  of  the  information  system.  For  the  data  component,  the  structure  of 
the  database  is  developed.  To  accomplish  that,  the  development  team  translates  the  user 
data  model  into  specific  data  structures.  For  the  process  component,  the  process  model 
IS  transformed  into  an  application  design. 

1.  Logical  Database  Design 

After  the  semantic  objects  are  developed,  the  next  step  is  to  transform  these 
objects  into  a  relational  design  The  resulting  relations  are  then  normalized  This  is  a 
very  important  part  of  the  design  because  we  need  to  be  sure  that  the  objects'  relations 
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will  not  suffer  from  any  update  anomalies.  The  process  of  normalization  is  discussed  in 
the  following  section. 

u  Normalization 

Normalization  is  the  process  of  forming  well-designed  relations  by 
grouping  attributes  together.  This  process  examines  the  relations  to  test  if  they  are  in  one 
of  the  predefined  normal  forms.  The  normalization  process  ensures  data  is  stored  in  a 
maimer  that  minimizes  data  redundancy  and  update  anomalies  while  maintaining  data 
integrity.  The  normal  forms  are  shown  in  figure  5. 
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As  indicated  in  figure  5,  each  of  the  higher  normal  forms  contains  the  lower  ones. 
This  means,  for  example,  that  a  relation  that  is  in  the  third  normal  form  is  also  in  both 
first  and  second  normal  forms.  Therefore  the  steps  in  the  normalization  process  are 
progressive  and  one  normal  form  follows  another.  In  each  step  only  certain  anomalies 
are  eliminated.  It  is  mandatory  for  relational  database  designers  to  satisfy  the 
requirements  of  all  the  normal  forms  to  ensure  that  all  anomalies  have  been  eliminated 

(1)  First  Normal  Form  (INF) 

A  relation  is  in  the  first  normal  form  if  it  has  no  repeating  groups. 
That  means  that  all  the  attributes  in  the  relation  are  atomic.  Since  this  is  the  definition 
of  the  relation,  we  can  safely  say  that  every  normalized  relation  is  in  the  first  normal 
form 

(2)  Second  Normal  Form  (2NF) 

A  relation  is  in  the  second  normal  form  if  it  is  in  first  normal  form 
and  all  non-key  attributes  are  dependent  on  all  the  attributes  of  the  key.  If  the  key  is  a 
single  attribute  then  the  relation  is  automatically  in  the  second  normal  form.  If  the  key 
IS  a  set  of  attributes  then  all  the  non-key  attributes  must  be  fully  functionally  dependent 
on  that  key. 
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(i)  Third  Normal  Form  (3NF) 


A  relation  is  in  the  third  normal  form  if  it  is  m  second  normal  form 
and  it  has  no  transitive  dependencies.  A  transitive  dependency  occur  if  A->B,  B-^C,  then 
A->C 

(4)  Boyce-Codd  Norma!  Form  (BCNF) 

A  relation  is  in  Boyce-Codd  normal  form  if  it  is  in  third  normal  form 
and  every  determinant  is  a  candidate  key;  any  attribute  that  functionally  determines  any 
other  attribute  is  a  candidate  key. 

(5)  Fourth  Normal  Form  (4NF) 

A  relation  is  in  the  fourth  normal  form  if  it  is  in  Boyce-Codd  normal 
form  and  the  multivalued  dependencies  are  eliminated.  This  case  exists  when  there  are 
more  than  two  attributes  in  a  relation,  two  of  them  are  multivalued,  and  their  values 
depend  only  on  a  third  attribute. 

(6)  Fifth  Normal  Form  (5NF) 

A  relation  is  in  the  fifth  normal  form  if  it  is  in  forth  normal  form 
and  does  not  have  a  joint  dependency. 

(7)  Domain  /  Key  Normal  Form  (DK/NF) 

A  relation  is  in  Domain/Key  normal  form  if  every  constraint  of  the 
relation  is  a  logical  consequence  of  the  definition  of  keys  and  domains.  A  domain  is  a 
description  of  the  allowed  values  of  an  attribute.  Fourth,  fifth  and  the  domain/key  normal 
forms  have  little  practical  usefulness  and  are  usually  ignored  in  practice. 


22 


2.  Application  Design 

The  design  phase  includes  the  design  of  both  the  database  and  the  application 
An  application  is  the  collection  of  menus,  forms,  reports,  and  programs  that  provide  a 
means  of  update,  display,  and  control  the  objects  of  the  data  model.  During  the 
application  design,  the  specific  structure  of  forms,  reports,  menus,  and  query  facilities  are 
defined.  Also,  the  logic  of  transaction  programs  that  will  be  written  for  the  system  is 
developed.  The  application  design  will  be  discussed  further  in  chapter  IV. 

E.  DATABASE  IMPLEMENTATION 

The  system's  implementation  is  the  set  of  activities  following  the  logical  design,  and 
consists  of  the  production  of  a  working  system  that  accepts  input  from  the  user,  processes 
data  and  produces  the  desired  outputs  One  very  important  task  during  the  development 
of  a  software  application  is  the  development  of  the  user's  manual. 

F.  OTHER  CONSIDERATIONS 

Important  issues  such  as  testing,  security,  training,  conversion,  maintenance,  and 
future  upgrades  vidll  be  considered  and  discussed  later  in  chapter  VI. 

Testing  has  been  defined  as  "the  fiendish  and  relentless  process  of  executing  all  or 
part  of  a  system  with  the  intent  of  causing  it  to  exhibit  a  defect"  (Page-Jones,  1988,  p. 
358)  The  testing  phase  has  traditionally  involved  first  the  testing  of  separate  parts  of  the 
system  and  then  the  testing  of  the  system  as  a  whole.  The  whole  system  is  then  turned 
over  for  acceptance  testing  (quality  assurance).  Acceptance  testing  is  carried  out  by  the 
user,  the  user's  representatives,  the  analysts,  the  standards  group,  external  system  auditors. 


or  any  combination  thereof.  Structured  techniques  emphasize  the  interweaving  of  the 
testing  phase  as  much  as  possible  with  the  implementation  phase  so  that  the  system 
quality  is  "built  in"  rather  than  "added  in"  after  the  fact.  The  development  of  test  cases 
and  a  test  plan  can  begin  at  the  end  of  analysis  and  be  carried  out  during  the  design  phase 
itself  This  will  ensure  that  testing  is  ready  to  begin  as  soon  as  the  implementation  phase 
commences. 

1.  Testing  Techniques 

All  testing  involves  the  following  six  steps: 

a.  Select  what  is  to  be  measured  by  the  test.  The  goal  of  the  test  must  be 
determined.  Are  the  requirements  to  be  tested  for  completeness?  Is  the  code  being  tested 
for  reliability?  Is  the  design  being  tested  for  cohesion? 

b.  Decide  how  whatever  is  being  tested  is  to  be  tested.  A  decision  of  how  to  test 
for  quality  must  be  made.  A  wide  variety  of  approaches  are  available,  including 
inspection,  proofs,  black  box  and  white  box  testing,  and  automated  methods.  The  tester 
must  decide  what  kind  of  test  is  to  be  used  to  measure  the  desired  quality. 

c.  Develop  the  test  cases.  Once  the  actual  test  has  been  decided  the  actual  test 
cases  must  be  created.  A  test  case  is  simply  a  set  of  data  or  situations  that  will  be  used 
to  exercise  the  unit  being  tested. 

d  Determine  the  correct  or  expected  results  from  the  test  and  create  the  test  oracle 
It  IS  very  important  for  the  tester  to  know  what  the  correct  result  should  look  like,  and 
determine  the  "test  oracle"  which  is  the  predicted  results  for  a  set  of  test  cases. 

e.  Execute  the  test  cases.  In  this  step  the  tester  has  to  carry  out  all  the  tests. 
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f.  Compare  the  results  of  the  tests  to  the  test  oracle.  A  very  careful  comparison 
between  the  actual  results  of  the  test  and  the  test  oracle  should  be  done  in  this  step.  Any 


discrepancy  between  the  predicted  results  and  the  actual  results  signals  an  error.  The 
source  of  the  error  must  be  tracked  down.  In  most  cases  the  error  is  in  the  system  that 
is  being  tested.  However,  in  some  cases,  the  error  may  be  in  the  testing  process  or  in  the 
test  oracle. 

In  order  to  understand  the  testing  techniques  more  clearly  let's  take  the  sample 
system  of  figure  6,  and  see  in  what  ways  this  system  can  be  tested.  Figure  6  shows  a 
sample  modular  hierarchy  of  a  hypothetical  system.  Modules  A,B,C,D,E,F  and  G 
represent  parts  of  the  developed  units/code  to  be  tested. 


Figure  6.  Sample  Modular  Hierarchy 


a  Traditional  Approach  to  Testing 

Figure  7  shows  the  traditional  testing  technique  which  requires  testing 
every  module  after  its  completion  phase,  integrating  the  whole  system,  and  testing  the 
complete  system  at  once.  Following  the  traditional  testing  technique  the  tester  may 


experience  difficulties  at  the  integration  point  where  he  has  to  test  the  complete  system 
and  where  most  of  the  problems  are  surfaced. 


Figure  7:Traditional  Testing 


b.  Top-down  Testing  Strategy 

In  this  case  the  testing  procedure  is  driven  by  the  system  modular 
hierarchy  and  follows  the  top  down  design.  Figure  8  shows  the  top-down  testing  strategy 
which  is  characterized  by  relatively  early  integration,  no  need  for  module  drivers  (modules 
that  are  not  fully  implemented),  low  work  parallelism  at  the  beginning,  and  difficulty  in 
testing  particular  paths,  and  planning  and  controlling  the  sequence  of  tests. 
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Figure  8:Top-down  Testing 


c.  Bottom-tqf  Testing  Strategy 


Figure  9  shows  the  bottom-up  testing  strategy  in  which  every  individual 
module  is  tested  starting  from  the  bottom  and  working  backwards  to  the  top.  This 
technique  is  characterized  by  late  integration,  need  for  module  drivers,  medium  work 
parallelism  at  the  beginning,  ability  to  test  particular  paths  easily,  and  difficulty  to  plan 
and  control  the  sequence  of  tests. 


Figure  9;  Bottom-up  Testing 


d.  Sandwich  Testing  Strategy 

Figure  10  shows  the  sandwich  testing  strategy  which  is  a  combination  of 
both  top-down  and  bottom-up  testing  strategies,  and  ensures  that  all  the  modules  have 
been  implemented  as  soon  as  the  "Test  A,  B,  C,  D,  E,  F,  G"  modules  have  been  tested. 
This  technique  is  characterized  by  early  integration,  medium  work  parallelism  at  the 
beginning,  medium  ability  to  test  particular  paths,  and  difficulty  to  plan  and  control  the 
sequence  of  tests. 


2.  Security 

Database  security  is  important  because  databases  are  so  critical  to  an 
organization.  Even  with  an  efficient  operating  system,  data  is  at  risk  if  a  reliable  database 
system  is  not  used.  Operating  systems  usually  protect  data  at  the  fiie  level.  Databases 
however  need  protection  at  different  levels  such  as  table  or  relation,  row  or  tuple,  or  even 
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element.  In  addition,  different  discretionary  security  policies  are  often  desired  for 
database  systems  that  restrict  access  to  specific  data  through  specific  operations,  such  as 
insert,  update,  retrieve  and  delete  Such  controls  are  not  available  in  operating  systems 

There  are  seven  conceptual  requirements  for  database  security.  These  are 
authentication,  access  control,  availability,  physical  integrity,  logical  integrity,  element 
integrity  and  audit  trail.  There  is  a  certain  amount  of  dependence  between  these  seven 
aspects,  since  a  failure  in  one  area  may  expose  the  database  to  increased  vulnerability 
from  the  remaining  areas. 

A  uthentication  is  the  requirement  to  positively  identify  every  user  of  the  database. 
This  may  be  achieved  through  the  use  of  information  known  only  to  a  particular  user, 
(e.g.  password),  the  use  of  some  physical  item,  (e.g.  a  key  or  pass  card),  or  reference 
to  some  physical  aspect  of  the  user  (e  g.  fingerprints,  voice  pattern). 

Access  control  defines  the  who  and  the  what  of  allowed  activities  on  the  system's 
data.  The  who  describes  which  subjects  have  access  to  which  objects.  The  what  defines 
the  operations  (e.g.  read,  write,  etc.),  allowed  on  each  object.  Figure  11  shows  an 
example  of  an  access  control  list  for  three  users  and  three  relations.  This  sample  access 
control  list  permits  user  "X"  to  access  relation  "A"  to  insert,  read,  update  and  delete  data. 

A  vailabilit}’  means  that  authonzed  users  should  not  experience  denial  of  service. 

Physical  security  involves  protecting  the  media  which  stores  the  database  from 
damage.  This  may  include  measures  to  protect  the  physical  media  from  natural  disasters, 
fire,  and  accidental  or  intentional  abuse. 
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Figure  11;  Access  Control  List  Example 

Logical  integrity  involves  protecting  information  about  the  logical  structure  (schema) 
of  the  database,  which  in  many  occasions  is  stored  separately  from  the  base  data. 
Element  integrity  is  concerned  with  the  accuracy  and  correctness  of  the  data  in  each  data 
element. 

A  udit  trails  answer  the  -who,  what  and  when  about  access  to  data  in  the  database. 
It  is  a  permanent  record  of  who  has  accessed  what  elements  of  the  database,  what  actions 
were  performed  upon  them,  and  when  the  action  took  place. 

3.  Conversion 

The  conversion  phase  is  probably  the  most  important  phase  of  the  system 
implementation  from  a  managerial  perspective.  This  is  the  time  that  users  and  system 
development  personnel  have  to  work  closely  together.  Human  nature  is  to  resist  any  kind 
of  changes,  especially  if  they  are  not  ready  or  prepared  for  that  change.  Factors  such  as 
organizational  structure,  human  resources,  and  political  and  cultural  climate  all  come  into 
play.  Management  sometimes  has  to  restructure  the  organization  chart  when  a 
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computerized  system  is  implemented  into  the  organization  environment  Human  resources 
are  often  reallocated  to  and  from  the  new  system  so  the  pnnciple  of  "the  right  man  in  the 
right  position"  will  be  guaranteed.  Conflicts  among  users  and  workers  who  don't  believe 
in  automation  should  be  expected.  Furthermore,  some  employees  view  training  programs 
as  a  threat  because  they  believe  that  evaluations  made  at  the  end  of  the  training  will  be 
used  against  them. 

a.  Strategies 

There  are  four  strategies  that  can  be  used  to  implement  a  system. 

They  are;  Parallel  Conversion,  Direct  Conversion,  Phased  Conversion,  and  Pilot 
Conversion. 

(1)  Parallel  Conversion 

Figure  12  shows  the  parallel  conversion  technique  which  is  widely  used.  It 
consists  of  operating  both  the  old  and  the  new  system  at  the  same  time,  until  management 
IS  satisfied  that  the  new  system  is  working  efficiently.  At  this  point  the  old  system  is 
discontinued.  This  technique  eliminates  the  risk  involved  with  implementing  a  new 
system,  but  requires  a  lot  of  manpower  to  maintain  both  systems  in  operation. 
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Figure  12:  Parallel  Conversion 


(2)  Direct  Conversion 

Figure  13  shows  the  direct  conversion  which  is  characterized  by 
shutting  down  the  old  system  at  the  end  of  one  workday  and  starting  up  the  new  system 
the  next  workday.  This  technique  can  be  extremely  risky,  but  it  is  gaining  in  popularity 
over  the  parallel  convers  on  strategy  for  the  following  reasons: 

•  By  using  the  parallel  approach,  the  need  for  manpower  is  greater. 
Furthermore,  by  continuing  with  the  old  system,  it  may  cause  some  users  not 
to  make  a  genuine  effort  to  supoort  the  new  system 

•  With  thorough  testing  of  the  system  and  training  of  the  personnel,  the  new 
system  should  operate  at  acceptable  levels 

•  In  many  cases  the  risk  of  failure  of  the  new  system  may  be  acceptable 
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Figure  13:  Direct  Conversion 


(i)  Phased  Conversion 

Figure  14  shows  the  phased  conversion  technique  through  which  the 
old  system  is  phased  out  and  the  new  system  is  gradually  phased  in.  This  approach  has 
many  of  the  same  problems  that  parallel  conversion  has,  primarily  because  both  systems 
operate  simultaneously.  Furthermore,  the  outputs  of  the  two  systems  have  to  be  combined 
to  obtain  a  total  picture  Finally,  by  shifting  to  the  new  system,  no  backup  of  the  old  one 
exists,  and  if  the  new  system  fails  then  the  only  way  to  retrieve  lost  information  is  by 
reverting  completely  to  the  old  system.  The  big  advantage  is  that  the  shift  from  the  old 
system  to  the  new  one  is  quite  smooth  As  the  user  gradually  becomes  familiar  with  the 
new  system  while  continuously  using  it,  he  starts  seeing  the  advantages  of  the  new 
system  This  is  a  key  factor  in  minimizing  user  resistance. 
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(4)  Pilot  Conversion 

Figure  15  shows  the  pilot  conversion  technique.  Pilot  conversion 
consists  of  implementing  the  new  system  in  a  selected  portion  of  its  ultimate  site.  If  the 
system  operates  efficiently  on  this  selected  portion,  it  is  then  fully  implemented  at  the 
entire  site.  Within  the  pilot  area,  the  system  can  be  implemented  in  any  of  the  previously 
discussed  methods.  The  pilot  approach  avoids  many  of  the  problems  that  the  other 
alternatives  have  One  drawback  however,  is  that  it  does  not  test  whether  the  system  will 
operate  satisfactorily  under  the  increased  volume  of  full  implementation. 
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Figure  15;  Pilot  Conversion 
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ffl.  REQUIREMENTS  ANALYSIS  FOR  SPAS 

In  this  chapter  we  will  discuss  both  the  data  and  the  process  requirements  for  the 
SPAS  application.  We  will  create  the  data  model  and  the  corresponding  data  flow 
diagrams  that  represent  the  data  flow  that  create,  update  and  display  the  objects  of  the 
data  model. 

A.  DATA  REQUIREMENTS 

Data  requirements  are  captured  in  the  form  of  semantic  objects  and  associated  data 
dictionary.  This  application  consists  of  seventeen  (17)  semantic  objects  that  are  shown 
in  Appendix  A.  In  this  diagram  objects  and  object  properties  are  indicated  in  upper  case, 
attributes  in  mixed  case,  and  identifiers  are  underlined. 

1.  SHIP 

A  ship  has  a  name,  belongs  to  a  class,  is  commanded  by  a  Commanding 
Officer,  helped  by  an  Executive  Officer  and  belongs  to  a  higher  command.  The  ship 
internally  is  organized  into  DEPARTMENTS. 

2.  DEPARTMENT 

A  department  has  a  name,  is  controlled  by  the  department  head  who  is  an 
officer,  and  has  an  office  and  a  phone  number.  It  belongs  to  the  SHIP  and  contains  and 
controls  one  or  more  DIVISIONS. 
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3.  DIVISION 


Similar  to  a  department,  a  division  has  a  name,  is  controlled  by  the  division 
officer,  and  ha  office  and  phone  number.  Every  division  has  one  or  more  PERSONS 
and  belongs  to  ..  DEPARTMENT. 

4.  PORT  DUTY  STATION 

A  port  duty  station  that  the  PERSON  could  be  assigned  to  while  in  port  has 
a  name,  a  location  and  a  phone  number. 

5.  PERSON 

The  persons  onboard  the  ship  work  for  a  DIVISION.  Every  person  has  a 
unique  identification  number,  a  first  and  last  name,  a  military  rank  and  rate,  owns  a 
current  position  after  being  reassigned  from  his  previous  one  on  a  certain  date,  has  a 
specialty,  and  should  belong  to  three  different  division  systems  in  order  to  be  able  to 
complete  his  individual  tasks  depending  on  the  general  ship's  situation.  These  systems 
are  the  one  third  crew  division  system  that  applies  when  the  ship  is  underway  with  three 
watch  shifts,  the  one  half  that  applies  when  the  ship  is  on  two  shifts  and  a  session 
division  system  that  applies  every  morning  while  in  port  for  the  XO's  daily  report.  Every 
person  has  a  date  of  birth,  an  address,  has  to  provide  his  nearest  police  station  address  and 
phone  number  in  case  of  emergency,  has  a  religion,  hobbies,  background  education  and 
may  speak  one  or  more  foreign  languages.  As  soon  as  he  embarks  he  is  assigned  a 
berthing  place,  some  SPECIAL  DUTIES,  a  PORT  DUTY  STA  TION ,  an  ABANDON 
SHIP  STA  TION  in  case  of  an  abandon  drill  or  a  real  situation  and  one  or  more  SPECIAL 
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STA  TION  when  the  ship  is  mooring,  anchoring  towing  or  being  towed.  At  any  time,  a 
person  has  the  right  to  take  LEA  VE  or  to  ask  for  a  SPECIAL  REQUEST  The  command 
is  also  interested  in  other  personal  data,  like  the  person's  DEPENDENTS,  his  FITNESS 
condition,  his  PROMOTIONS  and  some  work  experience  data,  such  as  being  qualified  as 
an  air  controller  and  his  current  qualification  category.  Any  time  he  performs  AIR 
CONTROL  CHECKS  it  is  recorded  and  the  ship  is  required  to  report  it  every  month 
Furthermore,  all  personnel  are  subject  to  penodic  ON  THE  JOB  TRAINING 
EVALUATIONS.  Finally,  a  person  undertakes  TRAINING  and  is  subject  to 
DISCIPLINARY  actions. 

6.  SPECIAL  STATION 

A  special  station  that  the  PERSON  could  be  assigned  to  has  a  type  and  a  title. 
The  person  has  a  duty  and  has  to  carry  some  equipment  and  there  is  a  location  where  all 
the  persons  have  to  be  gathered. 

7.  SPECIAL  DUTY 

Similar  to  the  station,  a  special  duty  that  the  PERSON  could  be  assigned  to 
has  a  type,  a  title  and  each  person  has  some  instructions.  They  have  to  carry  some 
equipment  and/or  some  armament  depending  on  the  mission  and  there  is  a  location  where 
they  have  to  be  gathered. 

8.  DEPENDENT 

The  crewmember's  (  PERSON  jdependent  has  a  name,  lives  at  an  address,  and 
has  a  phone  number.  There  is  a  possibility  that  the  crewmember  has  other  dependents. 
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9.  DISCIPLINARY 


Any  PERSON  onboard  could  commit  an  "  illegal  "  action  and  be  disciplined. 
That  offense  reported  by  an  officer,  has  a  number,  a  name  and  a  date  when  it  was 
committed.  The  person  has  the  right  to  give  his  apology,  while  the  command  has  to 
decide  his  punishment,  the  date  that  punishment  starts,  and  the  date  that  it  ends. 

10.  PROMOTION 

Normally,  after  a  certain  period  of  time  the  PERSON s  onboard,  commissioned 
officers  and  petty  officers  get  promoted.  The  command  needs  to  know  the  promotion 
date,  the  command  issued  the  order  for  the  promotion  and  the  date  of  the  issued  order. 

11.  FITNESS  EVALUATION 

Once  a  year,  all  PERSONS  have  to  be  evaluated  for  their  fitness  condition. 
The  fitness  evaluation  has  a  reference  period,  a  start  date,  an  end  date,  a  pass  or  fail 
evaluation  grade  and  any  possible  comments. 

12.  ON  THE  JOB  TRAINING  (OJI)  EVALUATION 

PERSONS  periodically  are  evaluated  on  their  job  in  order  to  be  qualified  or 
to  refresh  their  technical  skills  and  knowledge.  The  OJT  evaluation  is  performed  by  the 
person's  department  head,  has  a  start  date,  an  end  date,  the  resulting  grade,  any  possible 
comments  and  the  station  that  the  person  is  qualified  for. 

13.  TRAINING 

The  training  of  crewmembers  is  a  continual  activity.  There  are  required 
schools  that  crewmembers  have  to  attend  in  order  to  get  promoted  and  there  are  schools 


whose  attendance  is  on  a  volunteer  basis  The  ship's  command  needs  to  know  what 
school  each  of  the  PERSONs  have  attended,  the  date,  the  degree  or  the  diploma,  the  grade 
that  the  person  obtained,  his  order  of  success  among  the  other  participants  and  any 
possible  comments 

14.  AIR  CONTROL  CHECK 

PERSONS  that  are  qualified  as  air  controllers  and  are  capable  of  performing 
tactical  control  on  fixed  wings  or  helicopters  have  to  record  each  control  check  they 
perform,  and  the  ship's  command  has  to  submit  a  consolidated  report  every  month  to  the 
Tactical  Training  Center.  The  air  control  check  has  a  date  and  a  time  that  the  control  was 
performed,  the  type  of  the  aircraft,  the  type  of  the  control  and  its  duration  and  possible 
comments. 

15.  LEAVE 

By  law,  each  person  is  entitled  to  30  days  normal  leave  every  year.  However, 
depending  on  the  situation  and  the  CO’s  decision,  he  could  get  additional  days  off.  This 
special  leave  could  be  for  personal/private  reasons  or  for  educational  purposes.  For 
example,  special  leave  could  be  granted  while  the  person  is  studying  at  a  university  and 
has  to  take  exams,  or,  it  could  be  given  as  a  reward.  The  PERSON'S  leave  is  described 
by  Its  type,  has  a  date  starts,  a  date  ends,  the  number  of  days  in  leave,  destination,  as  well 
as  any  possible  comments. 
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A  crewmember  serving  onboard  the  ship  can  submit  requests,  mostly 
concerning  administrative  issues.  He  can  ask  to  report  something  personal  to  the  CO  or 
the  XO,  or  ask  to  be  heard  by  the  higher  commander  or  even  by  the  Admiral  of  the  Fleet 
PERSON'S  request  has  to  be  recorded  and  has  a  date,  a  type,  a  description,  the  CO's 
decision  and  any  possible  comments. 

17.  ABANDON  SHIP  STATION 

On  the  "  ABANDON  SHIP  "  order,  everyone  has  to  be  at  his  abandon  ship 
station.  This  is  any  of  the  life  rescue  facilities  of  the  ship  either  a  rescue  boat  or  a 
floating  raft.  The  abandon  ship  station  has  a  number,  a  location,  a  type  and  a  capacity. 
All  of  the  PERSONS  are  assigned  to  an  abandon  ship  station. 

B.  DATA  DICTIONARY 

The  SPAS  application  data  dictionary  is  shown  in  Appendix  B.  It  describes  each 
object,  its  properties,  the  data  type,  width,  and  definition  of  each  property. 

C  PROCESS  REQUIREMENTS 

In  this  application,  the  decomposition  diagram  and  the  data  flow  diagrams  that 
describe  the  system's  functionality  are  shown  in  Appendix  C.  The  system  has  four  levels. 
The  zero  level  is  the  overall  system  picture  named  Shipboard  Personnel  Administration 
System  (  SPAS  ).  It  is  factored  into  three  different  subsystems  titled  Personnel 
Subsystem,  Request  Subsystem  and  Report  and  Query  Subsystem. 
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a  Personnel  Subsystem 

This  subsystem  has  five  processes:  process  crewmember  data,  process 
dependent  data,  process  disciplinary  data,  process  evaluation  data  and  maintain  person 
data.  The  process  evaluation  data  consists  of  two  subprocesses:  on  the  job  training 
evaluation  data  and  fitness  evaluation  data.  The  maintain  person  data  process  consists  of 
five  subprocesses  to  update  the  air  control,  crewmember,  dependent,  disciplinary  and 
evaluation  data.  All  these  subprocesses  have  add,  modify  and  delete  mechanisms.  Of 
special  interest  is  the  process  crewmember  data  process  through  which  all  of  a  person's 
data  IS  entered  into  the  system  as  well  as  his  assignment  to  special  duties  and  special 
stations 

b.  Request  Subsystem 

The  request  subsystem  has  only  two  processes  to  process  any  kind  of 
special  request  or  leave  request. 

c.  Report  and  Query  Subsystem 

This  subsystem  produces  predefined  reports  either  for  internal  or  external 
use  The  answer  specified  queries  process  is  considered  a  utility  for  the  production  of 
internal  reports  to  support  the  ship's  command  with  any  kind  of  information  relative  to 
a  person  The  produce  internal  reports  process  is  split  into  the  following  subprocesses: 
produce  person's  information  card,  produce  person's  information  book,  produce  fitness 
evaluation  report,  produce  a  division  system  report  and  produce  a  special  duty  report 
The  produce  external  reports  process  produces  the  air  controllers'  monthly  report,  the 
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officers'  special  report,  the  officers'  monthly  report,  the  sailors'  monthly  report  and  the 
sailors  punishment  monthly  report, 

D.  HARDWARE  REQUIREMENTS 

The  system  being  developed  will  be  implemented  on  an  IBM  compatible  PC 
platform  found  on  many  Hellenic  Navy  ships.  The  minimum  hardware  configuration  is 
a  386  SX  (16  bit  architecture)  processor  running  at  25  Mhz,  with  2  Mb  of  RAM  and  65 
Mb  of  hard  drive. 

The  following  chapter  will  describe  the  logical  database  and  application  design  for 

SPAS 
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rV.  LOGICAL  DATABASE  AND  APPUCATION  DESIGN  FOR  SPAS 

In  this  chapter  we  will  discuss  the  logical  database  and  application  design  for  SPAS. 
In  logical  database  design,  the  object  model  developed  in  the  previous  chapter  is 
transformed  into  a  relational  schema,  in  preparation  for  implementation  using  a  specific 
DBMS.  In  application  design,  the  data  flow  diagrams  are  used  as  a  basis  for  developing 
the  menus,  forms,  and  reports  for  SPAS. 

A.  LOGICAL  DATABASE  DESIGN 

The  seventeen  semantic  objects  describing  the  user's  environment  are  transformed 
into  nineteen  relations.  Relationships  are  represented  using  foreign  keys  and  are  also 
shown  explicitly  on  the  relational  diagram.  In  this  diagram,  shown  in  Appendix  D, 
primary  keys  are  underlined  and  foreign  keys  are  indicated  with  the  superscript 
Relations  of  Appendix  D,  their  attributes,  and  relationships  are  discussed  in  the  following 
sections. 

1.  Ship  Relation 

This  relation  contains  information  about  a  ship.  It  is  derived  from  SHIP 
object.  Its  primary  key  is  Hull  Number.  Other  attributes  are  Ship's  Name,  Ship's  Class, 
Commanding  Officer's  Name,  Executive  Officer's  Name,  and  Higher  Command.  It  has 
a  1;M  mandatory  relationship  to  Department  relation. 
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2.  Department  Relation 

This  relation  contains  information  about  a  department.  It  is  derived  from 
DEPARTMENT  object.  Its  primary  key  is  Department  Name  Other  attributes  are 
Department  Head,  Office  Location,  Phone  Number  and  Hull  #  (foreign  key).  It  has  a  M;  1 
and  a  1:M  mandatory  relationships  to  Ship  and  Division  relations  respectively 

3.  Division  Relation 

This  relation  contains  information  about  a  division.  It  is  derived  from 
hi  /ISION  object.  Its  primary  key  is  Division  Name.  Other  attributes  are  Division 
Officer  Name,  Office  Location,  Phone  Number  and  Department  Name  (foreign  key).  It 
has  a  M:1  and  a  l:M  mandatory  relationships  to  Division  and  Person  relations 
respectively. 

4.  Person  Relation 

This  relation  contains  information  about  a  person.  It  is  derived  from  PERSON 
object.  Its  primary  key  is  Personal  Identification  Number.  Other  attributes  are  Last 
Name,  First  Name,  Rank,  Rate,  Current  Position,  Previous  Position,  Date  of  Change, 
Specialty,  Date  of  Birth,  Address,  Nearest  Police  Station  and  Phone  Number,  One  Third 
Crew  Division  System  Number,  One  Half  Crew  Division  System  Number,  Session 
Number,  Berthing,  Religion,  Education,  Foreign  Languages,  Hobbies,  Air  Control 
Category,  Instructor  Air  Controller,  Division  Name  (foreign  key).  Port  Duty  Station  Name 
(foreign  key),  and  Abandon  Ship  Station  Number  (foreign  key).  It  has  a  M.  1  mandatory 
relationship  to  Port  Duty  Station,  Division,  and  Abandon  Ship  Station  relations,  all 
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optional  relationship  to  Fitness  Evaluation,  Dependent  and  Air  Control  Check,  a  1  M 
mandatory  relationship  to  Promotion,  Person-Special  Duty,  and  Person-Special  Station 
relations,  a  1:M  optional  relationship  to  Disciplinary,  Training,  Request,  Leave,  and  On 
the  Job  Training  Evaluation  relations. 

5.  Dependent  Relation 

This  relation  contains  information  about  a  person's  dependent  It  is  derived 
from  DEPENDENT  object,  its  primary  key  is  Dependent's  Name  and  Personal 
Identification  Number.  Other  attributes  are  Address,  Phone  Number  and  Other  Dependent 
Names.  It  has  a  1:1  mandatory  relationship  to  Person  relation. 

6.  Fitness  Evaluation  Relation 

This  relation  contains  information  about  a  person's  fitness  evaluation  It  is 
derived  from  FITNESS  EVALUATION  object.  Its  primary  key  is  Reference  Period  for 
Fitness  Evaluation  and  Personal  Identification  Number.  Other  attributes  are  Start  Date, 
End  Date,  Grade,  and  Comment.  It  has  a  1 .1  mandatory  relationship  to  Person  relation. 

7.  On  the  Job  Training  Evaluation  Relation 

This  relation  contains  information  about  a  person's  OJT  evaluation  It  is 
derived  from  OJT  EVALUATION  object.  Its  primary  key  is  Start  Date  for  the  OJT 
Evaluation  and  Personal  Identification  Number.  Other  attributes  are  End  Date,  Grade, 
Comments,  Station  duty  of  Qualification,  and  Officer  Performed  the  Qualification  It  has 
a  M:1  mandatory  relationship  to  Person  relation. 
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8.  Disciplinaiy  Relation 

This  relation  contains  information  about  a  person's  Disciplinary  actions.  It  is 
derived  from  DISCIPLINARY  object.  Its  primary  key  is  Offence  Number  and  Personal 
Identification  Number.  Other  attributes  are  Offence  Name,  Offence  Date,  Apology, 
Punishment,  Start  Date,  End  Date,  and  Reporting  Officer.  It  has  a  M:1  mandatory 
relationship  to  Person  .  elation 

9.  Training  Relation 

This  relation  contains  information  about  a  person's  Training.  It  is  derived  from 
TRAINING  object.  Its  primary  key  is  School  Name  and  Personal  Identification  Number. 
Other  attributes  are  Date,  Degree/Diploma,  Number  of  Participants,  Grade,  Order  among 
Participants,  and  Comments.  It  has  a  M:1  mandatory  relationship  to  Person  relation. 

10.  Promotion  Relation 

This  relation  contains  information  about  a  person's  Promotion.  It  is  derived 
from  PROMOTION  object.  Its  primary  key  is  Promotion  Date  and  Personal  Identification 
Number  Other  attributes  are  Command  Issued  the  Order,  and  Date  of  Issued  Order.  It 
has  a  M  l  mandatory  relationship  to  Person  relation. 

11.  Port  Duty  Station  Relation 

This  relation  contains  information  about  a  port  duty  station.  It  is  derived  from 
PORT  DUTY  STATION  object.  Its  primary  key  is  Port  Duty  Station  Name  Other 
anributes  are  Station  Location  and  Phone  Number  It  has  a  1:M  mandatory  relationship 
to  Person  relation. 

I 

I 
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12.  Air  Control  Check  Relation 


This  relation  contains  information  about  air  control  checks.  It  is  derived  from 
AIR  CONTROL  CHECK  object.  Its  primary  key  is  Date,  Time,  and  Type  of  Aircraft. 
Other  attributes  are  Type  of  Control,  Duration,  Comments  and  Personal  Identification 
Number  (foreign  key).  It  has  a  1:M  mandatory  relationship  to  Person  relation. 

13.  Request  Relation 

This  relation  contains  information  about  a  person's  requests.  It  is  derived  from 
REQUEST  object.  Its  primary  key  is  Date,  Personal  Identification  Number,  and  Type  of 
Request.  Other  attributes  are  Description,  CO's  Decision,  and  Comments.  It  has  a  M;  1 
mandatory  relationship  to  Person  relation. 

14.  Leave  Relation 

This  relation  contains  information  about  a  person's  leave.  It  is  derived  from 
LEAVE  object.  Its  primary  key  is  Date  Starts  and  Personal  Identification  Number.  Other 
attributes  are  Date  Ends,  Type  of  Leave,  Number  of  Days  on  leave.  Destination,  and 
Comments.  It  has  a  M:1  mandatory  relationship  to  Person  relation. 

15.  Abandon  Ship  Station  Relation 

This  relation  contains  information  about  an  abandon  ship  station.  It  is  derived 
from  ABANDON  SHIP  STATION  object.  Its  primary  key  is  Abandon  Ship  Station 
Number.  Other  attributes  are  Location,  Type  of  Rescue  Vessel,  and  Capacity.  It  has  a 
1:M  mandatory  relationship  to  Person  relation. 
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16.  Special  Station  Relation 

This  relation  contains  information  about  a  special  ship  station.  It  is  derived 
from  SPECIAL  STATION  object.  Its  primary  key  is  Special  Station  Type  and  Special 
Station  Title,  Other  attributes  are  Duty,  Equipments,  and  Gathering  Position/Location 
It  has  a  1:M  mandatory  relationship  to  Person-Special  Station  relation, 

17.  Peison-Special  Station  Relation 

This  relation  contains  information  about  a  person  and  his  special  ship  station. 
It  is  derived  from  PERSON  and  SPECIAL  STATION  objects.  It  is  an  intersection 
relation  that  breaks  the  many  to  many  relationships  between  person  and  special  station 
into  two  1;M  relationships.  Its  primary  key  is  Personal  Identification  Number,  Special 
Station  Type,  and  Special  Station  Title.  It  has  a  M:1  mandatory  relationship  to  Person 
and  Special  Station  relations. 

18.  Special  Duty  Relation 

This  relation  contains  information  about  a  special  ship  duty.  It  is  derived  from 
SPECIAL  DUTY  object.  Its  primary  key  is  Special  Duty  Type  and  Special  Duty  Title. 
Other  attributes  are  Duty  Instruction,  Equipments/Guns  and  Ammunition,  and  Gathering 
Position  It  has  a  1;M  mandatory  relationship  to  Person-Special  Duty  relation 

19.  Person-Special  Duty  Relation 

This  relation  contains  information  about  a  person  and  his  special  duty  It  is 
derived  from  PERSON  and  SPECIAL  DUTY  objects.  It  is  an  intersection  relation  that 
breaks  the  many  to  many  relationships  between  person  and  special  duty  into  two  1;M 
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relationships.  Its  primary  key  is  Personal  Identification  Number,  Special  Duty  Type,  and 
Special  Duty  Title.  It  has  a  M:1  mandatory  relationship  to  Person  and  Special  Duty 
relations. 

B.  APPUCATION  DESIGN 

In  application  design,  the  data  flow  diagrams  developed  in  the  requirements  phase 
are  used  as  the  basis  for  designing  the  system’s  menus,  forms,  and  reports.  The  following 
jection  provides  a  brief  explanation  of  each. 

1.  Menus 

SPAS  is  a  menu-driven  application.  The  reason  for  using  menus  is  because 
they  are  self  explanatory  and  are  therefore  easy  to  use.  The  menu  structure  of  SPAS 
follows  closely  the  decomposition  diagram  developed  during  process  requirements.  SPAS 
menus  are  shown  in  Appendix  E. 

2.  Forms 

Forms  are  the  user's  primary  interface  with  the  database.  They  are  used  for 
entering,  modifying,  and  displaying  data  retrieved  from  the  database.  Special  care  was 
paid  in  designing  the  forms  for  SPAS.  Every  effort  was  made  in  designing  them  to  be 
natural,  easy  to  use,  and  be  less  prone  to  errors.  SPAS  forms  are  shown  in  Appendix  F. 

3.  Reports 

Reports  are  the  main  output  that  the  system  generates  for  distribution  to  a 
variety  of  users.  Reports  can  be  sent  to  the  screen,  to  a  file,  or  to  the  printer.  Similar 
to  designing  forms  special  care  was  paid  in  designing  the  reports  for  SPAS.  Every  effort 
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was  made  in  designing  them  to  be  natural,  logical,  close  to  the  format  that  is  currently  in 
use,  and  less  prone  to  misinterpretation,  SPAS  reports  are  shown  in  Appendix  G. 
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V.  IMPLEMENTATION  FOR  SPAS 

In  this  chapter  we  will  discuss  the  implementation  of  the  SPAS  application  and  the 
construction  of  the  database,  as  well  as  the  installation  of  both  the  database  and  the  SPAS 
application.  The  Paradox  database  management  system  for  DOS  is  introduced  and  used 
as  the  DBMS  of  choise  for  SPAS  implementation. 

Paradox  is  a  fast,  full-featured,  and  easy  to  use  relational  database  program  designed 
to  meet  data  management  needs.  Paradox  can  be  used  by  computer  users  with  all  levels 
of  experience  from  beginning  database  users  to  advanced  developers.  Paradox  can  be 
used  either  on  a  single  computer  (standalone)  or  on  a  Local  Area  Network  (LAN). 

To  use  Paradox  4.0  on  a  standalone  computer,  you  will  need  at  a  minimum: 

•  a  100%  IBM  compatible,  protected  mode  capable  80286  or  higher  personal 
computer  with  a  hard  disk  and  a  floppy  drive 

•  2MB  extended  memory 

•  DOS  3.0  or  higher,  or  OS/2  2.0 

•  compatible  MDA,  MCA,  CGA,  EGA,  VGA,  8514,  3270,  ATT,  TANDY 
TIOOO,  or  Hercules  monitor  with  adapter 

•  5MB  of  free  hard  disk  space  to  install  Paradox  without  the  optional  software 
and  0.5MB  for  the  optional  software 

•  free  hard  disk  space  approximately  three  times  the  size  of  your  largest  table, 
to  process  complex  queries 
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The  user  interface  for  Paradox  supports  multiple  windows,  pull-down  menus,  speed 
bars,  dialog  boxes,  and  other  graphical  user  interface  components.  Paradox  provides 
limited  mouse  support.  For  instance,  you  can't  change  directories  when  loading  tables  by 
pointing  and  clicking  at  a  directory  tree  with  the  mouse;  you  have  to  type  your  path 
manually.  Paradox's  Query  By  Example  (QBE)  capability  is  one  of  the  product's  strong 
features.  Complex  queries  can  be  run  against  single  or  joined  tables,  and  query  images 
can  be  saved  for  later  use.  A  variety  of  exact  and  inexact  queries  can  be  performed,  and 
there  is  support  for  wildcards,  data  ranges,  pattern  searches,  and  logical  conditions 
Phonetic  searches  can  be  done  with  Paradox's  "Like"  operator.  Database  administration 
is  handled  through  Paradox's  well-designed  user  interface  which  puts  all  the  commands 
the  user  needs  on  easy-to-use  menus  and  provides  shortcut  keys  for  many  of  the  choices. 

A.  DATA  IMPLEMENTATION 

In  data  implementation,  the  relations  and  their  attributes  developed  during  logical 
database  design  are  transformed  into  tables  and  data  fields,  respectively.  Table  structures 
are  created  in  Paradox  by  choosing  Create  from  the  menu,  and  specifying  a  name  for  the 
new  table  in  the  -dialog  box.  The  structure  of  the  new  empty  table,  which  matches  the 
corresponding  relation  developed  during  the  design  phase,  is  then  specified.  For  each 
field  of  the  table,  its  name,  field  type,  and  whether  it  is  a  key  field  are  entered.  Brief 
descnptions  of  the  field  type  choices  are  displayed  on  the  new  table  creation  window  to 
assist  the  users  in  creating  the  new  table.  The  data  types  supported  by  Paradox  and  their 
abbreviations  are:  A  for  alphanumeric  fields  up  to  255  characters  in  length,  M  for  a  memo 


up  to  240  characters  in  table  view,  N  for  numbers,  $  for  currency  amounts,  and  D  for 
dates.  Once  the  definition  of  a  table  is  completed,  a  user  can  enter  values  in  the  table 
directly  or  through  a  form. 

B.  APPUCATION  IMPLEMENTATION 

A  Paradox  application  is  a  series  of  instructions  to  Paradox  that  makes  it  perform 
the  set  of  tasks  needed  to  do  a  specific  job.  These  instructions  link  menus,  forms, 
queries,  and  reports  into  a  comprehensive  system.  In  this  section  we  will  discuss  Paradox 
query  module,  form  and  report  generator,  and  application  workshop. 

Query  module  lets  the  user  select,  combine,  manipulate,  and  retrieve  data  in  tables. 
To  perform  a  query,  a  query  form  has  to  be  filled  out  first.  This  form  is  related  to  the 
table  that  contains  the  data.  The  A  sk  command  on  the  main  menu  displays  the  Query 
form.  Several  forms  can  be  linked  together,  and  the  designer  is  able  to  retrieve  all  the 
information  he  needs  into  a  single  table.  He  can  also  set  conditions  to  be  satisfied  whei 
the  query  is  performed.  Setting  conditions  is  a  simple  action  of  making  the  Query  form 
look  like  an  example  of  the  records  he  likes  to  retrieve.  This  is  called  Query  by  Example. 
The  retrieved  data  are  stored  in  a  temporary  table  named  Answer. 

Paradox  has  a  form/report  generator  that  allows  the  programmer  to  design  custom 
forms  and  reports.  Forms  are  used  to  input  data  one  record  at  a  time  A  form  can  have 
wrapped  fields  that  show  the  information  of  a  single  field  on  two  or  more  lines.  The 
information  in  a  table  image  is  always  arranged  in  rows  and  columns,  w'hereas  the 
information  on  a  form  can  be  arranged  in  a  free  format.  Data  fields  are  highlighted  in 
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different  colors  for  easy  recognition  with  a  cursor  that  tabs  from  one  logical  data  field  to 
the  next.  Forms  are  created  by  choosing  Form,  Design  from  the  menu.  Paradox  default 
IS  a  standard  tabular  formatted  form.  The  designer  has  the  option  to  design  a  custom  free 
format  form.  Appendix  F  shows  SPAS  data  input  forms 

Reports  are  produced  to  display  the  requested  information  from  the  database.  Each 
table  can  have  up  to  15  reports  defined  on  it.  Each  report  can  have  up  to  2000  characters 
per  line.  Reports  are  created  by  choosing  Report,  Design  from  the  menu.  Paradox  default 
is  a  standard  column  report.  The  designer  has  the  option  to  design  a  custom  free  format 
report.  Appendix  G  shows  SPAS  customized  reports. 

Paradox  application  workshop  helps  the  programmer  to  create  Paiadox  Applications 
easily.  The  application  menus  are  created  through  the  application  workshop.  Building 
the  menus  and  defining  what  each  command  menu  does  is  accomplished  through  the 
application  workshop.  The  application  workshop  creates  and  manages  the  components 
of  the  application.  Another  way  to  create  these  components  is  by  using  PAL 
(Programming  Application  Language)  scripts  which  is  more  complex  and  designed  for 
more  advanced  applications  and  experienced  programmers.  For  the  development  of  SPAS 
application,  a  combination  of  both  the  application  workshop  and  PAL  was  used. 

Appendix  H  shows  the  programming  code  generated  by  Paradox  while  building  the 
SPAS  application.  Part  one  of  the  Appendix  is  the  "Menu  Structure"  that  shows  the 
hierarchy  of  the  SPAS  application  menu  structure.  Part  two  is  the  cross-reference  table 
of  "Action  Objects  &  Paradox  Objects  in  Use"  that  explains  in  each  session  what  tables 
are  declared,  what  functions  (insert,  edit,  delete)  are  performed,  and  if  the  specific  session 
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is  password  protected.  Part  three  is  the  action  table  menu  that  describes  in  detail  how 
each  of  the  actions  is  performed. 

Appendix  I  provides  procedures  for  installing  and  operating  SPAS 
The  next  chapter  discusses  other  issues  that  need  to  be  taken  into  consideration 
before  SPAS  can  be  fully  operational. 


VI.  OTHER  ISSUES 


In  this  chapter  important  issues  concerning  the  development  of  the  "SPAS" 
application  such  as  testing,  security,  training,  conversion,  maintenance,  and  future 
upgrades  will  be  discussed. 

A.  TESTING 

As  mentioned  in  chapter  D,  testing  is  critical  for  the  development  of  the  SPAS 
application.  Database  management  system  testing  abilities  as  well  SPAS  testing  strategy 
will  be  discussed  at  this  point. 

1.  Paradox  Testing 

Paradox  is  designed  to  allow  the  developer  to  conduct  testing  through  the  use 
of  environments.  In  the  "Workshop"  environment,  after  each  programming  session  is 
implemented  the  user  is  able  to  test  the  specific  module  and  be  assured  that  it  is  fully 
functional  without  any  procedural  errors.  When  the  application  is  finished,  it  can  and 
must  be  tested  as  a  whole.  Paradox  has  that  feature  built  in  the  application  workshop 
under  "Application/Test"  which  tests  the  application  to  ensure  that  everything  after  the 
integration  works  properly. 

2.  ’SPAS"  Testing  Strategy 

As  mentioned  in  the  previous  paragraph,  Paradox  lets  the  developer  test  the 
application  at  every  procedural  step.  While  building  each  of  the  action  menus,  the 
developer  is  able  to  test  every  action,  session,  or  report,  to  ensure  that  everything  is 
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working  properly,  and  continue  to  the  next  menu  for  further  development.  So,  in  this 
session,  access  to  all  of  the  tables  and  forms  is  ensured,  adl  queries  are  performed,  and 
everything  is  verified  to  be  working  properly.  This  "built  in"  testing  procedure  in  Paradox 
represents  the  bottom-up  testing  strategy  that  is  described  in  paragraph  II.E.2  c  The 
bottom-up  testing  technique  was  performed  throughout  the  development  of  the  SPAS 
application  and  each  individual  process  was  tested  before  proceeding  to  the  next  higher 
step  in  the  application's  hierarchy.  Each  subsystem  was  tested  in  that  way  ensuring  no 
functional  or  procedural  errors  were  present.  The  whole  application  was  then  tested  as 
a  complete  and  integrated  system. 

B.  SPAS  SECURITY 

Paradox  offers  a  very  flexible  passwording  scheme  with  table-by -table, 
script-by-script,  and  option-by-option  password  protection.  Access  to  a  given  table  can 
be  limited  on  a  field-by-field  basis. 

SPAS  users  will  have  some  access  control  authorities  depending  on  their  rank  and 
their  duties  onboard  the  ship.  The  command  is  responsible  for  assigning  these  duties  and 
for  determining  each  user  access  control. 

SPAS  physical  security  falls  under  the  navy's  policy  and  procedures  that  enforce 
rules  and  activities  for  the  ships'  physical  security.  Moreover,  each  individual  ship 
command  has  to  take  proper  measures  to  protect  the  hardware  resources  as  well  as  the 
software  and  the  applications. 
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C  TRAINING 


One  of  the  most  important  aspects  of  the  implementation  phase  is  the  training  plan. 
The  training  plan  is  designed  to  ensure  that  every  user  of  the  system  knows  the  system's 
basic  functions  and  how  to  perform  them.  The  success  of  any  information  system 
depends  on  the  skills  of  the  operators.  In  the  SPAS  system,  the  operators  are  officers, 
petty  officers  and  sailors,  who  are  familiar  with  the  procedures  on  the  ship,  currently  run 
the  system  manually,  and  who  only  need  to  be  taught  how  the  new  system  operates.  The 
system  itself  is  designed  to  be  friendly,  easy-to-use,  and  does  not  require  the  operator  to 
have  any  advanced  interpersonal  skills.  However,  matching  basic  human  characteristics 
and  skills  with  a  job's  requirements  is  essential,  especially  when  an  automated  system  is 
to  replace  a  manual  one. 

The  designer's  proposal  for  the  training  is  to  start  with  the  main  users  of  the  system 
and  train  them  in  the  system's  environment  as  well  as  its  functions  and  operations,  The 
main  users  of  the  system  are  defined  as  personnel  working  in  the  ship's  administration 
office.  They  are  led  by  the  administration  officer  whose  team  normally  consists  of  two 
petty  officers  and  three  or  four  sailors.  As  soon  as  every  ship  has  a  trained  core  of 
system  users,  training  for  the  rest  of  the  personnel  can  be  held. 

D.  CONVERSION 

The  future  success  of  the  new  system  depends  on  how  well  and  how  quickly  it  is 
accepted  by  the  users.  With  SPAS  application,  it  is  hoped  that  because  the  system  is 
rather  small  and  the  users  are  already  familiar  with  the  environment,  proper  training  will 


minimize  these  problems.  Another  way  to  minimize  implementation  problems  is  to  select 
the  correct  conversion  strategy. 

1.  SPAS  Convetsion  Strategy 

For  the  SPAS  application  conversion  strategy,  the  pilot  approach  is  proposed 
A  parallel  conversion  within  two  Hellenic  Navy  ships  as  pilot  units  is  desired  for  the 
following  reasons: 

•  risk  IS  significantly  minimized 

•  testing  the  system  on  two  ships  over  a  penod  of  time  will  provide  sufficient 
information  to  evaluate  the  system  before  complete  implementation  on  all 
ships 

•  manpower  need  is  reasonable 

•  surfaced  problems  can  be  worked  out  by  the  personnel  of  both  ships 

•  time  to  shift  is  predicted  to  be  two  months  which  is  a  reasonable  interval  for 
checking  monthly  reports  and  for  reassigning  personnel  from/to  the  ship 

As  soon  as  the  system  operates  sufficiently  on  the  pilot  units,  a  decision  for  full 
implementation  on  all  ships  can  be  made. 

E.  MAINTENANCE 

Once  the  system  passes  the  acceptance  test,  it  is  ready  for  delivery  Any 
modifications  or  enhancements  after  delivery  is  called  maintenance.  Attention  should  be 
paid  to  the  fact  that  after  a  few  years  of  operating  the  original  system,  maintenance 
becomes  extremely  tedious,  error-prone,  and  expensive.  In  this  case,  management  should 
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recognize  the  problem  and  do  a  feasibility  study  on  replaci..g  the  old  system  with  a  new 


one. 


F.  FUTURE  ENHANCEMENTS 

The  SPAS  system  design  offers  a  flexible  way  for  future  upgrades  Paradox  itself 
can  be  distributed  on  a  network  and  allow  applications  to  be  shared  among  different  users 
The  SPAS  system  is  able  to  produce  all  the  designed  reports  in  file  format  This  facility 
allows  ships  to  electronically  transfer  their  reports  as  soon  as  all  the  commands  are 
connected  to  a  common  network. 
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vn,  CONCLUSIONS  AND  LESSONS  LEARNED 

This  thesis  presented  the  design,  development,  partial  testing  and  implementation 
of  the  Shipboard  Personnel  Administration  System  (SPAS)  application  on  a  standalone 
computer.  The  SPAS  system  will  provide  the  Hellenic  Navy  ships  with  an  automated 
system  to  perform  their  primaiy  administrative  functions.  SPAS  supports  this  mission  by 
keeping  track  of  all  the  personnel  records,  maintaining  them,  producing  reports  and 
providing  the  command  with  ad  hoc  information. 

No  automated  system  is  currently  in  use  and  all  the  administrative  activities  are 
performed  by  a  manual  filing  system  which  is  slow,  inaccurate  and  prone  to  errors.  The 
main  goal  of  developing  the  system  is  to  release  manpower  to  perform  other  duties,  by 
increasing  effectiveness,  efficiency,  and  accuracy  of  personnel  management.  After  SPAS 
implementation,  it  is  hoped  that  most  of  the  current  problems  will  be  eliminated,  and 
future  enhancements  will  result  in  even  greater  efficiency  in  performing  the  personnel 
administration  functions 

System  analysis  and  design  tools  and  techniques  were  used  to  develop  the  system 
by  modeling  the  user  data  and  process  requirements.  Paradox  for  DOS  was  used  as  the 
database  management  system  for  the  implementation  because  it  is  not  only  powerful  but 
also  meets  the  system's  developmental  requirements.  The  window  like,  pull-down  menu 
driven  environment  is  easy  to  use  and  quick  to  learn.  The  user  friendly  environment  will 
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hopefully  eliminate  the  cultural  resistance  of  the  user  that  will  result  from  the  requirement 
to  switch  from  the  manual  system  to  an  automated  one 

It  is  hoped  this  thesis  will  be  the  motivator  for  other  efforts  to  develop  new  systems, 
and  expand  or  update  existing  ones  in  the  Hellenic  Na  ped  also  that  the 

developed  system  would  benefit  other  services  of  the  Hellenic  military  and  give  them  the 
inspiration  to  develop  their  own  systems  following  the  pre-designed  and  tested  system 
designed  for  the  Navy  and  developed  in  this  thesis 
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APPENDIX  A:  SEMANTIC  OBJECTS 


SHIP 


DIVISION  PORT  DUTY  STATION 


SPECIAL  STATION  SPECIAL  DUTY 
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Personal  ID  # 

Last  Name 
First  Name 

Rate 

Current  Position 
Previous  Position 
Date  of  Change 
Specialty 

1/3  Crew  Division  # 

1/2  Crew  Division  # 

Sessitxi 
Date  of  Birth 
Address 

Nearest  Police  Station  &  Phone  # 
Berthing 

Air  Control  Categoiy 
Instructor  Air  Controler  (Y/N) 
Religion 
Education 

Foreign  Languages  mv 
Hobbies  mv 


TRAINING 


mv 


OJT  EVALUATION 


mv 


DEPENDENT 


PROMOTION 


mv 


DIVISION 


DISCIPLINARY 


mv 


ABANDON  SHIP  STATION 


SPECIAL  STATION 


mv 


SPECIAL  DUTIES 


mv 


REQUEST 


mv 


LEAVE 


mv 


AIR  CONTROL  CHECK 


mv 


FITNESS  EVALUATION 


PORT  DUTY  STATION 


PERSON 
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Dependent's  Name 

EERSQN 


Offence  # 
PERSON 


Address 
Phone  # 

Other  Depentent's  Name 


DEPENDENT 


Offence  Name 
Date  of  Offence 
Apology 
Punishment 
Start  Date 
End  Date 
Reporting  Officer 


DISCIPLINARY 


Promotion  Date 

PERSON 

Command  Issued  the  Order 
Date  of  Issued  Order 


PROMOTION 


Reference  Period 

PERSON 

Start  Date 
End  Date 
Grade 
Comments 


Start  Date 


End  Date 

Grade 

Comments 

Station  Duty  of  Qualification 
Officer  Performed  the  Qual. 


FITNESS  EVALUATION 


OJTEVALL.  N 
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School 


Dale 

lime 


PERSON 


mv 


Date 

Degree/Diploma 
No.  of  Participants 
Grade 

Order  of  Success  among  Participants 
Comments 


Type  of  Aircraft 
Type  of  Control 
Duration  of  Control 

Comments 


PERSON 


TRAINING  AIR  CONTROL  CHECK 


Date 

P.ERSQN 


Type  of  Request 
.Description 
C  O's  Decision 
‘  omments 


REQUEST 


Abandon  Ship  Station  # 
Location 

Type  of  Rescue  Vessel 
Capacity 

PERSON 


ABANDON  SHIP  STATION 


Date  Starts 
Date  Ends 


PERSON 


Type  of  Leave 
No.  of  Days 
Destination 
Comments 


LEAVE 
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APPENDIX  B:  DATA  DICTIONARY 


ELEMENT  TYPE  WIDTH 


SHIP  OBJECT 

Hull  # 

;Alphanumeric 

5 

Ship's  Name 

:Alphanumeric 

15 

Ship's  Class 

:  Alphanumeric 

15 

CO's  Name 

;  Alphanumeric 

25 

XO's  Name 

:  Alphanumeric 

25 

Higher  Command 

:AIphanumeric 

10 

DEPATRMENT 

:DEPARTMENT 
object;  MV 

DEPARTMENT  OBJECT 

Department  Name 

:  Alphanumeric 

15 

Department  Head 

;  Alphanumeric 

25 

Department  Office  Location 

:Alphanumeric 

10 

Department  Phone  # 

.Alphanumeric 

5 

SHIP 

:SHIP  object 

DIVISION 

:DIVISION 
object;  MV 

DIVISION  OBJECT 

Division  Name 

lAlpheinumeric 

15 

Division  Officer  Name 

:  Alphanumeric 

25 

Division  Office  Location 

;Alphanumeric 

10 

Division  Phone  # 

:  Alphanumeric 

5 

PERSON 

:PERSON 
object;  MV 

DEPARTMENT 

:DEPARTMENT 

object 

DESCRIPTION 


Ship's  Hull  #. 

Ship's  Name. 

Ship's  Class. 

CO's  Name. 

XO's  Name. 

Higher  Command  that  the 
ship  belongs  to. 


Name  of  the  Department. 
Name  of  the  Department 
Officer. 

Location  of  the 
Department  Office. 
Department  Office  Phone  #. 


Name  of  the  Division. 
Name  of  the 
Division  Officer. 
Location  of  the 
Division  Office. 

Division  Office  Phone  #. 
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PORT  DUTY  STATION  OBJECT 


Port  Duty  Station  Name 

;  Alphanumeric 

15 

Name  of  the 

Port  Duty  Station. 

Location 

:  Alphanumeric 

10 

Location  of  the 

Port  Duty  Station. 

Phone  # 

PERSON 

•Alphanumeric 
:PERSON 
object;  MV 

5 

Port  Duty  Station  Phone  # 

PERSON  OBJECT 

Personal  ID  # 

rAlphanumeric 

10 

Person's 

Identification  Number. 

Last  Name 

lAlphanumeric 

15 

Person's  Last  Name. 

First  Name 

:  Alphanumeric 

15 

Person's  First  Name. 

Rank 

rAlphanumeric 

1 

Person's  Rankr 

Or  if  Officer, 

Pr  if  Pety  Of, 

Sr  if  Sailor. 

Rate 

rAlphanumeric 

7 

Person's  Rate. 

Current  Position 

rAlphanumeric 

15 

Crewmember  Current 
Position  of  his  Job. 

Previous  Position 

rAlphanumeric 

15 

Crewmember  Previous 
Position  of  his  Job. 

Date  of  Change 

rDate 

6 

mm/dd/yy 

Date  of  Change  from 
Previous  Position  to 
Current  Position. 

Specialty 

rAlphanumeric 

15 

Person's  Specialty. 

1/3  Crew  Division  Number 

rAlphanumeric 

1 

Number  of  "1/3 

Crew  Division  System". 

1/2  Crew  Division  Number 

rAlphanumeric 

1 

Number  of  "1/2 

Crew  Division  System". 

Session  Number 

rAlphanumeric 

1 

Number  of  XO's 

Daily  Session. 

Date  of  Birth 

•.Date 

6 

Person’s  DoB, 
mm/dd/yy. 

Address 

rAlphanumeric 

30 

Person's  Home  Address. 

Nearest  Police  Station 

&  Phone  # 

rAlpheinumeric 

50 

Police  Station 

closest  to  Person's  Home. 

Berthing 

rAlphanumeric 

10 

Person's  Berthing  Place. 
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Air  Control  Category 

:Alphanumeric 

1 

Category  of  the 

Air  Controller. 

(if  the  person  is, 

"N"  if  he  is  not). 

Instructor  Air  Controller 

.Alphanumeric 

1 

"Y"  if  he  is  Instructor, 
"N"  if  he  is  not. 

Religion 

.Alphanumeric 

12 

Person's  Religion. 

Education 

:Alphanumeric 

12 

Person's  Undergraduate 
Education. 

Foreign  Languages 

;  Alphanumeric 

25 

Foreign  Languages 
spoken  by  the  Person. 

Hobbies 

:Alphanumeric 

25 

Person's  Hobbies. 

TRAINING 

:TRAINING 
object;  MV 

OJT  EVALUATION 

;OJT  EVALUATION 
object;  MV 

DEPENDENT 

:DEPENDENT 

object 

PROMOTION 

:PROMOTION 
object;  MV 

FITNESS  EVALUATION 

WITNESS 

EVALUATION 

object 

DIVISION 

:DIVISION  object 

DISCIPLINARY 

;DISCIPLINARY 
object;  MV 

ABNDON  SHIP  STATION 

:ABANDON  SHIP 
STATION  object 

SPECIAL  STATION 

;SPECIAL  STATION 
object;  MV 

SPECIAL  DUTY 

:SPEa  AL  DUTY 
object;  MV 

Ri;OUEST 

;REQUEST 
object;  MV 

LEAVE 

;LEAVE  object;  MV 

AIR  CONTROL  CHECK 

:AIR  CONTROL 
CHECK  object;  MV 

PORT  DUTY  STATION 

:PORT  DUTY 

STATION  object 

70 


DEPENDENTS  OBJECT 


Dependent's  Name 

:  Alphanumeric 

25 

Name  of  Person's 

Closest  Dependent. 

Dependent's  Address 

.Alphanumeric 

25 

Address  of  the 

Dependent. 

Dependent's  Phone  # 

:  Alphanumeric 

10 

Dependent's  Phone  #. 

Other  Dependents'  Name 

PERSON 

:  Alphanumeric 

.PERSON  object 

30 

Names  of  Other 

Possible  Dependents. 

DISCIPLINARY  OBJECT 

Offence  # 

;  Alphanumeric 

4 

Number  of  the 
Offence:"mmdd". 

Offence  Name 

:Alphanumeric 

20 

Name  of  the  Offence. 

Date  of  Offence 

:Date 

6 

mm/dd/yy 

Apology 

;Memo 

100 

Person's  Apology. 

Punishment 

;  Alphanumeric 

3 

Imposed  Punishment. 

Start  Date 

:Date 

6 

mm/dd/yy 

End  Dale 

:Date 

6 

mm/dd/yy 

Reporting  Officer 

PERSON 

:  Alphanumeric 

:PERSON  object 

25 

Name  of  the 

Reporting  Officer. 

PROMOTION  OBJECT 

Promotion  Date 

:Date 

6 

mm/dd/yy 

Command  Issued  the  Order 

:  Alphanumeric 

10 

Higher  Command 

Issued  the  Promotion  Order. 

Date  of  Issued  Order 

PERSON 

:Date 

:PERSON  object 

6 

mm/dd/yy 

FITNESS  EVALUATION  OBJECT 

Reference  Period 

lAlphanumeric 

4 

Period  that  Fitness 
Evaluation  is  referred  to; 
(mmyy). 

Start  Date 

;Date 

6 

mm/dd/yy 

End  Date 

:Date 

6 

mm/dd/yy 

Grade 

;  Alphanumeric 

1 

"P":if  Pass; 

”F";if  Fail. 

71 


Comments 

:Memo 

50 

PERSON 

:PERSON  object 

OJT  EVALUATION  OBJECT 

Start  Date 

:Date 

6 

End  Date 

;Date 

6 

Grade 

:  Alphanumeric 

1 

Comments 

:Memo 

50 

Station  Duty  of  Qualification 

.Alphanumeric 

15 

Officer  Performed  the 

Qualification 

:  Alphanumeric 

25 

PERSON 

.‘PERSON  object 

TRAINING  OBJECT 

School 

:Alphanumeric 

15 

Date 

:Date 

6 

Degree/Diploma 

:  Alphanumeric 

20 

No.  of  Participants 

;Alphanumeric 

2 

Grade 

;Alphanumeric 

3 

Order  of  Success 

among  Participants 

:Alphanumeric 

2 

Comments 

.‘Memo 

50 

PERSON 

:PERSON 
object;  MV 

AIR  CONTROL  CHECK  OBJECT 

Date 

:Date 

6 

Time 

.‘Alphanumeric 

4 

10 


Any  possible  comments. 


mm/dd/yy 

mm/dd/yy 

Pass; 

Fail. 

Any  possible  comments. 
Duty  Station  that  Person  is 
Qualified  for. 

Name  of  the  Officer 
Performed  the  Qualification 


School  that  Person 
has  Participated, 
mm/dd/yy 
Degree  or  Diploma 
achieved. 

Number  of  Persons 
Participated  at  the 
specific  School. 

Grade  achieved 
in  percentage  % 

Person’s  Order  of  Success 
among  the  Participants. 
Any  possible  comments. 


mm/dd/yy 

Time  that  Control  was 
performed  (hhmm). 

Type  of  Aircraft  Controlled. 


Type  of  Aircraft 


:  Alphanumeric 


Type  of  Control 


•Alphanumeric 


1  Type  of  Conti  ol 
for  the  Flight; 

"P"  :Positive; 

"A"  ;Advisory; 

"T"  :Tactical  Directions: 
"F"  :Free/No  Control. 


Duration  of  Control 

:  Alphanumeric 

4 

Duration  time  of  Control 
(hhmm). 

Comments 

PERSON 

:Memo 

:  PERSON  object 

50 

Any  possible  comments. 

LEAVE  OBJECT 

Date  Starts 

:Date 

6 

mm/dd/yy 

Date  Ends 

:Date 

6 

mm/dd/yy 

Type  of  Leave 

Alphanumeric 

15 

Type  of  Leave. 

No.  of  Days 

:  Alphanumeric 

2 

No.  of  Days  on  Leave. 

Destination 

:  Alphanumeric 

25 

Location  of  the  Person 
during  his  Leave. 

Comments 

PERSON 

:Memo 

■PERSON  object 

50 

Any  possible  comments. 

REQUEST  OBJECT 

Type  of  Request 

lAlplianumeric 

15 

Type  of  Request  that  a 
Person  could  have. 

Date 

;Date 

6 

mm/dd/yy 

Description 

:Memo 

30 

Short  Description  of 
Person's  Request. 

CO's  Decision 

rAlphanumeric 

1 

CO's  Decision; 

"Y"  if  Yes,  "N"  in  No. 

Comments 

PERSON 

-Memo 

:  PERSON  object 

50 

Any  possible  comments. 

SPECIAL  DUTY  OBJECT 

Type  of  Duty 

;Alphanumeric 

20 

Type  of  Special  Duty. 

Duty  Title 

:  Alphanumeric 

15 

Title  of  Special  Duty. 

Duty  Instructions 

;Memo 

30 

Given  Special  Instructions 

Equipment/Gun+Amo 

:Memo 

30 

Any  Equipments, 
Gun+Amo  carried. 

Gathering  Position 

;  Alphanumeric 

10 

Location  of  the 

Gathering  Station. 
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PERSON 


iPERSON 
object:  MV 


SPECIAL  STATION  OBJECT 


Station  Type 

;  Alphanumeric 

20 

Type  of  Special  Station. 

Title 

:Alphanumeric 

15 

Title  of  Special  Station. 

Duty 

•.Alphanumeric 

20 

Assigned  Duty. 

Equipment 

;Memo 

30 

Any  Equipments  carried. 

Gathering  Position/Location 

:Alphanumeric 

10 

Location  of  the 

Gathering  Station. 

PERSON 

:PERSON 

object;  MV 

ABANDON  SHIP  STATION  OBJECT 

Station  Number 

:  Alphanumeric 

3 

Number  of  the  Abandon 

Ship  Station. 

Location 

•.Alphanumeric 

10 

Location  of  the  Station. 

Type  of  Rescue  Vessel 

:  Alphanumeric 

20 

Type  of  the  Rescue  Vessel 

Capacity 

:Number 

2 

Capacity  of  the 

Rescue  Vessel. 

PERSON 

:PERSON  object 
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APPENDIX  C:  DATA  FLOW  DUGRAMS 
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APPENDIX  E:  APPUCATION  MENUS 
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APPENDIX  G:  APPUCATION  REPORTS 


mm/dd/yy  Personal  Information  Card  Page  5 


Personal  ID  # ;  AAAAAAAAAA  Division  Name;  AAAAAAAAA/iAAAAA 

Port  Duty  Station  Name;  AAAAAAAAAAAAAAA 

Last  Name  ;  AAAAAAAAAAAAAAA 
First  Name:  AAAAAAAAAAAAAAA 

Rank;  A  Rate;  AAAAAAA  Current  Posision;  AAAAAAAAAAAAAAA 

Specialty:  AAAAAAAAAAAAAAA  Berthing;  AAAAAAAAAA 

Abandon  Ship  Station  #;  AAA  Location;  AAAAAAAAAA 

1/3  Crew  Division  System;  A 
1  '2  Crew  Division  System;  A 
Session:  A 

Special  Station  Type;  AAA 
Title;  AAAAAAAAAAAAAAAAAAAA 
Duty:  AAAAAAAAAAAAAAAAAAAA 

Equipment  :  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Gathering  Position;  AAAAAAAAAA 

Type  of  Special  Duty:  AAAAAAAAAAAAAAAAAAAA 
Duty  Title:  AAAAAAAAAAAAAAA 

Duty  Instructions:  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Equipment /Gun«Amo;  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Gatnering  Position;  AAAAAAAAAA 


Personal  Information  Card  Format 


mm, dd/yy  Personnel  Fitness  Evaluation  Report  Page  3 


Personal  ID  #;  AAAAAAAAAA  Rank: A  Reference  Period :AAAA 

Last  Name  ;  AAAAAAAAAAAAAAA  Rate; AAAAAAA  Grade.  A 

First  Name:  AAAAAAAAAAAAAAA  Specialty '.AAAAAAAAAAAAAAA 
Date  of  Birth;  mm/dd/yy 

Start  Date:  mm/dd/yy  End  Date;  mm/dd/yy 

Comments  :  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


Fitness  Evaluation  Report  Forrmat 
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•nrr  aa,  '/v 


;mcsr' s  ocecia. 


P'irscr.al  ZC  Las'  rirsi  Name  Race  Address 

AAAAAAAAAA  AAAAAAAAAAAAAAA  AAAAAAA  AAAAAAAAAAAAAAAAA;: 
AAAAAAAAAAAAAAA  RanK  ;  A 
specialcy:  AAAAAAAAAAAAAAA 

Nearest  Police  scacion  i  pr.or.e  Nr 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 


Officer's  Special  Report  Format 


mm  /  30,'  '/v 


Officers'  Monthly  Report 


Person  10  Rank  Rata  Last  Name  Current  Pos .  Address 

AAAAAAAAAA  A  AAAAAAA  AAAAAAAAAAAAAAA  AAAAAAAAAAAAAAA  AAAAAAAAAAAAAAAAAAAAAAA 

First  Name  Previous  Pos. 

Specialty  AAAAAAAAAAAAAAA  AAAAAAAAAAAAAAA 
AAAAAAAAAAAAA  Date  of  Change 

mm/dd/'vy 


Officer's  Monthly  Report  Format 


mm,'  dd/'/y 


Petty  Officers'  Monthly  Repo: 


Last  Name  Rank  Rate  Person  ID  Current  Pos .  Address 

AAAAAAAAAAAAAAA  A  AAAAAAA  AAAAAAAAAA  AAAAAAAAAAAAAAA  AAAAAAAAAAAAAAAAAAAAAAAA 
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1/3  Crew  Division  System  Report  Format 


XO  Daily  Session  Division  System  Report  Format 
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mm/dd/ yy 

Special  Station  .Report 

Page  9 
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Div.  ;  Title 

A  AAAAAAA 

1/3;A  AAAAAAAAAAAAAAAAAAAA 

Locat  ion 

AAAAAAAAAAAAAAA 
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1/2;  A  Duty 
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AAA.XAAAAAAAAAAA 
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Berthing : 

AAAAAAAAAA 

Equipment;  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Special  Station  Report  Format 


Abandon  Ship  Station  Report  Format 

ni 


Tfr.,  dd,  v^/ 


Personal  Inf or-nacion  3CCK  PECORC 


r  a-e 


Hull  AAAAA 
Oeparrmenc  Name : 


Ship's  Name:  AAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAA  E  i  v 


:3niO '  s 


.asd 


si  on  Name  : 


Personal  :::  a.  .\AAAAAAAAA  Last:  /  Firsc  Name.-  AAAAAAAAAAAAAAA ,  AAAAAAAAAAAAAAA 
RanK :  A  Rare  :  AAAAAAA  3pecia_tiy:  AAAAAAAAAAAAAAA  Lars  of  3irtr.  :dci  tim 
Li'/isior.  Name;  AAAAAAAAAAAAAAA  Port;  Dury  Stacion  Name;  AAAAAAAAAAAAAAA 

Abandon  Ship  Scan  ion  4;  AAA 

lurrenc  Posision;  AAAAAAAAAAAAAAA 

Previous  Position ;  AAAAAAAAAAAAAAA  Dace  of  Change;  mm/dd/yy 

1'3  Crew  Division  System:  A 
1,  2  Crew  Division  System;  A 
Session:  A 

Address  ;  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Near  Police  St .  i  ohone  #;  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Religion:  AAAAAAAAAAAA  Hobbies :  AAAAAAAAAAAAAAAAAAAAAAAAA 

Education:  AAAAAAAAAAAA  Foreign  Languages;  AAAAAAAAAAAAAAAAAAAAAAAAA 

Sclnool  ;  AAAAAAAAAAAAAAA  Date:  mm/dd/yy 
Degree/Diploma:  AAAAAAAAAAAAAAAAAAAA 

Comments ;  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


I  Prom.ction  Dace;  mm/dd/yy 
j  Command  Issued  the  Order:  AAAAAAAAAA 
I  Date  of  Issued  Order;  mm/dd/yy 

T'/pe  of  Leave :  AAAAAAAAAAAAAAA 

Dace  Starts:  mm/dd/yy  Dace  Ends;  mm/dd/yy  No.  of  Days;  AA 
Comments- 1;  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

Offence  #:  AAAA  Offence  Name;  AAAAAAAAAAAAAAAAAAAA 

Date  of  Offence;  mm/dd/yy  Punishment;  AAA 

Type  of  Duty:  AAAAAAAAAAAAAAAAAAAA  Ducv  Title;  AAAAAAAAAAAAAAA 

Duty  Instructions:  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


Personal  Information  BOOK  /  RECORD 


mm.  oc/w 


Air  Control  Monthly  Report 


Page  9 


»ast  Name ;  AAAAAAAAAAAAAAA 
.Pa.-..<  A  Rate ;  AAAAAAA 

A_r  Control  Cateaorv:  A 


First  Name ; AAAAAAAAAAAAAAA 
Specia-ty:  AAAAAAAAAAAAAAA 
Instructor  .Air  Contrcler;  A 


Date,  mm,  dd,  yy  Type  of  .A,  C 

- 1  me  :  AA^\A  AAAhAAAAAA  Type  ot  ..ontro*;  A  Duration  ot  Contrc*.  AAAA 

Comments  ;  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


Air  Control  Monthly  Report  Format 
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APPENDIX  H:  SYSTEM’S  PROGRAM  AND  CODE 


A.  PART  ONE:  DOCUMENTATION  OF  MENU  STRUCTURE 
SPAS  -  Shipboard  Personnel  Administration  System 
Menu  Tree 

Documentation  of  Menu  Structure 


MAIN 

—  PERSONNEL  SUBSYSTEM  Enter  All  Personal  Data  to  the  System 

! —  PROCESS  CREWMEMBER  DATA  Enters  Crewmember  Data  to  the  System 
—  PROCESS  DEPENDENT  DATA  Enters  Crewmembers'  Dependent  Data  to  the  System 
I —  PROCESS  DISCIPLINARY  DATA  Enters  Crewmembers'  Disciplinary  Data  to  the  System 
j —  PROCESS  EVALUATION  DATA  Enters  Crewmembers'  Evaluation  Data 

I 

I  ! —  PROCESS  on  EVALUATION  DATA  Enters  Crewmembers'  On  Evaluation  Data 

!  I 

^  PROCESS  FITNESS  EVALUATION  DATA  Enters  Crewmembers'  Fitness  Data 
L  MAINTAIN  PERSON  DATA  Updates  all  Personnel  Data 
’ —  UPDATE  /UR  CONTROL  DATA  Keeps  Track  of  Air  Control  Data 

i 

—  UPDATE  PROMOTION  DATA  Updates  Personnel  Promotion  Data 
i —  UPDATE  CREWMEMBER  DATA  Updates  Crewmembers’  Personal  Data 
! —  ADD  DATA  Adds  Crewmember  Data 

I  ; 

I  ' —  MODIFY  DATA  Modifieb  Crewmember  Data 
I  —  DELETE  DATA  Deletes  Crewmember  Data 
■ —  UPDATE  DEPENDENT  DATA  Updater,  Crewmembers'  Dependent  Data 
' —  ADD  DATA  Adds  Dependents  Data 

I —  MODIFY  DATA  Modifies  Dependents  Data 
I  —  DELETE  DATA  Deletes  Dependents  Data 


114 


—  UPDATE  DISCIPLINARY  DATA  Updates  Crewmembers'  Disciplinary  Data 
—  ADD  DATA  Adds  Disciplinary  Data 

—  MODIFY  DATA  Modifies  Disciplinary  Data 
—  DELETE  DATA  Deletes  Disciplinary  Data 

—  UPDATE  EVALUATION  DATA  Updates  Crewmembers'  Evaluation  Data 

I —  ADD  DATA  Adds  Evaluation  Data 

j —  MODIFY  DATA  Modifies  Evaluation  Data 
' —  DELETE  DATA  Deletes  Evaluation  Data 

—  REQUEST  SUBSYSTEM  Handle  Personnel  Requests 

' —  PROCESS  SPECIAL  REQUEST  Enters  the  System  Crewmembers'  Special  Requests 
—  PROCESS  LEAVE  REQUEST  Enters  the  System  Crewmembers'  Leave  Requests 

—  REPORT  SUBSYSTEM  Generates  All  th>i  Reports 
h-  ANSWER  SPECIFIED  QUERIES  Answer  Queries 

' —  QUERY  PERSON  AND  DEPENDENT  Query  Crewmember  and  his  Dependent  Data 

I 

^ —  QUERY  PERSON  AND  SPECIAL  STATION  Query  Crewmember  and  his  Special  Station  Data 
! —  QUERY  PERSON  AND  DIVISION  SYSTEM  Query  Crewmember  and  his  Division  Data 

—  QUERY  PERSON.TRAINING, EVALUATION  Query  Crewmember's  Training  and  Evaluation  Data 

—  PERS0N,REQUEST,LEAVE,0JT,DISCIPL  Query  Crewmember  and  his  Request.Leave,  OJT 

Evaluation  and  Disciplinary 

■ —  PRODUCE  INTERNAL  REPORTS  Produce  Reports  for  Ship's  Use 

■ —  PERSONAL  INFORMATION  CARD  Produce  Personal  Information  Card 
' —  PERSONAL  INFORMATION  BOOK  Produce  Personal  Information  Book 
■ —  FITNESS  EVALUATION  REPORT  Produce  Crewmembers'  Fimess  Evaluation  Report 
—  DIVISION  SYSTEM  REPORT  Produce  Division  Systems  Reports 
■ —  1/3  SYSTEM  Produce  1/3  Crew  Division  System  Report 

■ —  1/2  SYSTEM  Produce  1/2  Crew  Division  System  Report 

—  SESSION  SYSTEM  Produce  Session  Division  System  Report 
—  SPECIAL  DUTY  STATION  REPORT  Produce  Special  Stations  Reports 

'  ' —  ALERT  STATION  Produce  Alert  Station  Report 

'  I 
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I  I —  MOOR-ANCHO-TOW  STATION  Produce  Ship's  Maneuvers  Station  Report 

^ —  ABANDON  SHIP  STATION  Produce  Abandon  Ship  Station  Report 
i  ^ —  PRODUCE  EXTERNAL  REPORTS  Produce  Reports  for  Higher  Commands 

—  AIR  CONTROLLER  MONTHLY  REPORT  Produce  A/C  Monthly  Report 
—  OFFICER  SPECIAL  REPORT  Produce  Officers’  Special  Report 
^  OFFICER  MONTHLY  REPORT  Produce  Officers'  Monthly  Report 
—  PETTY  OFFICER  MONTHLY  REPORT  Produce  Petty  Officers'  Monthly  Report 
! —  SAILOR  MONTHLY  REPORT  Produce  Sailors'  Monthly  Report 
I  ^ —  SAILOR  PUNISHMENT  MONTHLY  REPORT  Produce  Sailors'  Punishment  Monthly  Report 

—  EXIT  Exit  the  System 

—  EXIT  TO  PARADOX  Exit  this  Application  but  stays  in  PARADOX 
- <Separator> 

—  EXIT  TO  DOS  Exits  PARADOX  and  Goes  to  DOS 
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B.  PART  TWO;  DOCUMENTATION  OF  ACTION  MENU 


SPAS  -  Shipboard  Personnel  Administration  System 


Edit  Session:  SNl  lA 


Mode.  DataEntry 
Passwords:  As  Needed 
Prompt: 

Tables  Declared:  1 
Table  1:  PERSON 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Ins,Edit 

On  Tablelist: 

Prompt:  Enters  the  System  Personal  Data 


Edit  Session:  SNUB 


Mode.  DataEntry 
Passwords:  As  Needed 
Prompt: 

Tables  Declared.  1 
Table  1:  PROMOTIO 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes.  Ins,Edit 

On  Tablelist: 

Prompt:  Enters  the  System  Person's  Promotion  Data 


Edit  Session:  SNI  1C 

Mode:  DataEntry 

Passwords;  As  Needed 
Prompt; 

Tables  Declared:  1 

Table  1;  PERSTATN 

Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Ins,Edit 

On  Tablelist; 

Prompt:  Assigns  Person  to  Special  Stations 


Edit  Session:  SNI  ID 

Mode:  DataEntry 

Passwords:  As  Needed 
Prompt: 

Tables  Declared:  1 

Table  1:  PERSDUTY 

Initial  View:  Form 
Allowed  Views:  Form 
Use  Form;  1 
Modes:  Ins,Edit 

On  Tablelist: 

Prompt:  Assigns  Person  to  Special  Duties 


Edit  Session:  SNI 2 

Mode  DataEntry 
Passwords;  As  Needed 
Prompt: 

Tables  Declared:  1 
Table  1:  DEPENDEN 
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Initial  View.  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Ins,Edit 

On  Tablelist: 

Prompt:  Enters  the  System  Person's  Dependent  Data 


Edit  Session.  SN124 


Mode:  DataEntry 

Passwords:  As  Needed 
Prompt. 

Tables  Declared:  1 
Table  T.  FITNESS 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Ins,Edit 

On  Tablelist: 

Prompt:  Enter  to  the  System  All  Personnel  Fitness  Evaluation  Data 


Edit  Session:  SN13 


Mode  DataEntry 
Passwords:  As  Needed 
Prompt: 

Tables  Declared:  1 
Table  1  DESCIPLN 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  lns,Edit 

On  Tablelist: 

Prompt. 
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Edit  Session:  SN141 


Mode.  DataEntry 
Passwords.  As  Needed 
Prompt: 

Tables  Declared;  1 
Table  1:  OJT-EVAL 


Initial  View;  Form 
Allowed  Views;  Form 
Use  Form:  1 

Modes:  Ins.Edit 

On  Tablelist. 

Prompt.  Enters  the  System  Personal  OJT  Evaluation  Data 

Edit  Session:  SNI51 


Mode:  DataEntry 

Passwords;  As  Needed 
Prompt. 

Tables  Declared:  1 
Table  1:  AIR-CTRL 


Initial  View;  Form 
Allowed  Views;  Form 
Use  Form:  1 

Modes:  Ins,Edit 

On  Tablelist: 

Prompt;  Enters  the  System  Air  Control  Data 


Edit  Session:  SNI52 


Mode:  DataEntry 

Passwords:  As  Needed 
Prompt. 

Tables  Declared;  1 
Table  1:  PROMOTIO 


Initial  View:  Form 
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Allowed  Views.  Form 
Use  Form;  1 
Modes;  Ins.Update 

On  Tablelist: 

Prompt.  Updates  Personnel  Promotion  Data 

Edit  Session:  SNI531 

Mode:  DataEntry 

Passwords;  As  Needed 
Prompt: 

Tables  Declared.  1 
Table  I:  PERSON 


Initial  View;  Form 
Allowed  Views.  Form 
Use  Form:  1 

Modes:  Ins.Update 

On  Tablelist: 

Prompt;  Adds  Crewmember  Data 


Edit  Session:  SN1532 

Mode:  Edit 

Passwords  As  Needed 
Prompt: 

Tables  Declared:  1 
Table  I  PERSON 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  I 

Modes  Edit 

On  Tablelist; 

Prompt  Modifies  Crewmember  Data 


Edit  Session:  SNI533 

Mode.  Edit 
Passwords:  As  Needed 
Prompt; 
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Tables  Declared;  1 
Table  1:  PERSON 


Initial  View;  Form 
Allowed  Views;  Form 
Use  Form;  1 
Modes:  Del,Edit 

On  Tablelist; 

Prompt;  Deletes  Crewmember  Data 


Edit  Session:  SN1S41 


Mode:  DataEntry 

Passwords:  As  Needed 
Prompt; 

Tables  Declared:  1 
Table  1:  DEPENDEN 


Initial  View:  Form 
Allowed  Views;  Form 
Use  Form;  1 
Modes:  Ins, Update 

On  Tablelist; 

Prompt;  Adds  Dependent  Data 


Edit  Session:  SN1542 


Mode.  Edit 
Passwords.  As  Needed 
Prompt; 

Tables  Declared;  1 
Table  1 ;  DEPENDEN 


Initial  View;  Form 
Allowed  Views:  Form 
Use  Form.  1 
Modes;  Edit 

On  Tablelist. 

Prompt:  Modifies  Dependent  Data 
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Edit  Session:  SNI543 

Mode.  Edit 
Passwords.  As  Needed 
Prompt; 

Tables  Declared:  1 

Table  1:  DEPENDEN 

Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Del,Edit 

On  Tablelist: 

Prompt:  Deletes  Dependent  Data 


Edit  Session.  SNI551 


Mode.  DataEntry 
Passwords;  As  Needed 
Prompt: 

Tables  Declared.  1 

Table  1 :  DESCIPLN 

Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Ins.Update 

On  Tablelist: 

Prompt.  Adds  Disciplinary  Data 


Edit  Session:  SN1552 

Mode;  Edit 
Passwords;  As  Needed 
Prompt: 


123 


Tables  Declared:  1 


Table  1  DESCIPLN 


Initial  View.  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Edit 

On  Tablelist: 

Prompt:  Modifies  Disciplinary  Data 


Edit  Session:  SN1S53 


Mode:  Edit 

Passwords:  As  Needed 
Prompt: 

Tables  Declared:  1 
Table  1;  DESCIPLN 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form.  1 
Modes:  Del.Edit 

On  Tablelist; 

Prompt;  Deletes  Disciplinary  Data 

Edit  Session:  SN1561 

Mode:  DataEntry 

Passwords:  As  Needed 
Prompt: 

Tables  Declared:  1 
Table  1:  OJT-EVAL 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Ins, Update 

On  Tablelist. 

Prompt:  Adds  OJT  Evaluation  Data 


124 


Edit  Session:  SNI562 


Mode:  Edit 

Passwords:  As  Needed 
Prompt: 

Tables  Declared:  1 
Table  1  OJT-EVAL 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  1 

Modes:  Edit 

On  Tablelist: 

Prompt:  Modifies  OJT  Evaluation  Data 


Edit  Session:  SN1S63 


Mode;  Edit 
Passwords:  As  Weeded 
Prompt: 

Tables  Declared:  1 
Table  1:  OJT-EVAL 


Initial  View;  Form 
Allowed  Views;  Form 
Use  Form;  1 
Modes:  Del,Edit 

On  Tablelist: 

Prompt:  Deletes  OJT  Evaluation  Data 


Edit  Session:  SN21 


Mode:  DataEntry 

Passwords:  As  Needed 
Prompt: 

Tables  Declared:  1 
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Table  1;  REQUEST 


Initial  View;  Form 
Allowed  Views:  Form 
Use  Form  1 
Modes.  lns,Edit 
On  Tablelist: 

Prompt 


Edit  Session:  SN22 

Mode:  DataEntry 

Passwords:  As  Needed 
Prompt 

Tables  Declared:  1 
Table  1  LEAVE 


Initial  View  Form 
Allowed  Views  Form 
Use  Form;  1 
Modes  Ins.Edit 
On  Tablelist 
Prompt 


Edit  Session.  SN311 

Mode  DataEntry 
Passwords  As  Needed 

Prompt  Enter  the  Crewmember  Last/First  Name 
Tables  Declared:  1 
Table  1  AD-HOC 


Initial  View  Form 
Allowed  Views  Form 
Use  Form  F 
Modes  Ins,Edit 
On  Tablelist 
Prompt 

Edit  Session:  SN312 

Mode  DataEntry 
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Passwords:  As  Needed 

Prompt:  Enter  the  Crewmember  Last/First  Name 
Tables  Declared:  1 
Table  1:  AD-HOC 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  F 

Modes:  Ins,£dit 

On  Tablelist: 

Prompt: 


Edit  Session:  SN313 


Mode.  DataEntry 
Passwords:  As  Needed 

Prompt:  Enter  the  Crewmember  Last/First  Name 
Tables  Declared:  1 
Table  1:  AD-HOC 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  F 

Modes:  Ins,Edit 

On  Tablelist: 

Prompt: 


Edit  Session:  SN3I4 


Mode.  DataEntry 
Passwords:  As  Needed 

Prompt  Enter  the  Crewmember  Last/First  Name 
Tables  Declared:  1 
Table  1:  AD-HOC 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  F 

Modes:  Ins,£dit 
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On  Tablelist 
Prompt: 


Edit  Session  SN3 1 5 


Mode;  DataEntry 
Passwords.  As  Needed 

Prompt:  Enter  the  Crewmember  Last/First  Name 
Tables  Declared;  1 
Table  1  AD-HOC 


Initial  View:  Form 
Allowed  Views:  Form 
Use  Form:  F 

Modes:  Ins  Edit 

On  Tablelist: 

Prompt: 


Multiple  Actions.  MAll 

Actions  Called: 

1)  Edit  Session:  SNllA 

2)  Edit  Session:  SNUB 

3)  Edit  Session:  SNllC 

4)  Edit  Session;  SNllD 

[X]  Quit  if  Action  fails 


Multiple  Actions  MA3 1 1 


Actions  Called: 

1)  Edit  Session;  SN311 

2)  Play  a  Script  Adhocl 

3)  Report  Print:  PRN31 1 

4)  Play  a  Script;  Empty 

[X]  Quit  if  Action  fails 
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Actions  Called: 


1)  Edit  Session;  SN312 

2)  Play  a  Script:  Adhoc2 

3)  Report  Print:  PRN312 

4)  Play  a  Script;  Empty 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA313 

Actions  Called; 

1 )  Edit  Session;  SN313 

2)  Play  a  Script:  Adhoc3 

3)  Report  Print:  PRN313 

4)  Play  a  Script:  Empty 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MAS  14 

Actions  Called; 

1)  Edit  Session:  SN314 

2)  Play  a  Script.  Adhoc4 

3)  Report  Print:  PRN314 

4)  Play  a  Script:  Empty 

[X]  Quit  if  Action  fails 


Multiple  Actions.  MAS  15 

Actions  Called: 

1)  Edit  Session:  SN315 

2)  Play  a  Script:  AdhocS 

3)  Report  Print:  PRN315 

4)  Play  a  Script;  Empty 
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[X]  Quit  if  Action  fails 


Multiple  Actions:  MA316 


Actions  Called: 

1)  Play  a  Script:  Q321 

2)  Report  Print:  PRN321 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA322 


Actions  Called; 

1)  Play  a  Script;  Q322 

2)  Report  Print:  PRN322 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA323 


Actions  Called; 

1)  Play  a  Script;  Q323 

2)  Report  Print.  PRN323 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA324A 


Actions  Called; 

1)  Play  a  Script:  Q324a 

2)  Report  Print;  PRN324A 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA324B 
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Acrions  Called. 


1)  Play  a  Script:  Q324b 

2)  Report  Print;  PRN324B 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA324C 


Actions  Called: 

1)  Play  a  Script;  Q324c 

2)  Report  Print:  PRN324C 


[X]  Quit  if  Action  fails 


Multiple  Actions:  MA325A 


Actions  Called: 

1)  Play  a  Script:  Q325a 

2)  Report  Print:  PRN325A 

(X]  Quit  if  Action  fails 


Multiple  Actions:  MA325B 


Actions  Called. 

1 )  Play  a  Script;  Q325b 

2)  Report  Print:  PRN325B 

[X]  Quit  if  Action  fails 


Multiple  Actions  MA325C 


Actions  Called: 

1)  Play  a  Script;  Q325c 

2)  Report  Print:  PRN325C 

[X]  Quit  if  Action  fails 
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Actions  Called: 


1)  Play  a  Script:  Q331 

2)  Report  Print:  PRN331 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA332 

Actions  Called: 

1)  Play  a  Script:  Q332 

2)  Report  Print:  PRN332 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA333 


Actions  Called: 

1)  Play  a  Script:  Q333 

2)  Report  Print:  PRN333 

[X]  Quit  if  Action  fails 

Multiple  Actions:  MA334 

Actions  Called. 

1)  Play  a  Script:  Q334 

2)  Report  Print:  PRN334 

[X]  Quit  if  Action  fails 


Multiple  Actions:  MA335 


Actions  Called: 

1 )  Play  a  Script:  Q335 

2)  Report  Print:  PRN335 
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[X]  Quit  if  Action  fails 


Actions  Called: 


1)  P’  Script;  Q336 

2)  R  Print:  PRN336 


[X]  Quit  if  Action  fails 


Table:  ANSWER 
Report  U:  R 


Use  Data  From:  Listed  Table 

Output  Devices:  Screen 

Display  Working  Message:  Yes 

Working  Message:  Here  is  the  Requested  Data 

Printer  Port:  Default 

Page  Break:  Default 

Prefix  String;  None 

Suffix  String:  None 

Setup  Proc:  None 

Cleanup  Proc:  None 


Table  ANSWER 
Report  #:  R 


Use  Data  From;  Listed  Table 

Output  Devices:  Screen 

Display  Working  Message:  Yes 

Working  Message:  Here  is  the  Requested  Data 

Printer  Port:  Default 

Page  Break:  Default 


Prefix  String;  None 

Suffix  String:  None 

Setup  Proc:  None 

Cleanup  Proc:  None 


1 

Report  Print:  PRN313 


Table  ANSWER 
Report  #;  R 

Use  Data  From:  Listed  Table 

Output  Devices;  Screen 

Display  Working  Message;  Yes 

Working  Message  Here  is  the  Requested  Data 

Printer  Port:  Default 

Page  Break;  Default 

Prefix  String:  None 

Suffix  String:  None 

Setup  Proc:  None 

Cleanup  Proc:  None 


Report  Print:  PRN314 


Table:  ANSWER 
Report  #;  R 


Listed  Table 
Screen 

Display  Working  Message;  Yes 

Working  Message:  Here  is  the  Requested  Data 


Use  Data  From; 
Output  Devices: 


Printer  Port: 
Page  Break: 
Prefix  String: 
Suffix  String: 
Setup  Proc: 
Cleanup  Proc; 


Default 

Default 

None 

None 

None 

None 


Report  Print:  PRN315 


Table:  ANSWER 
Report  #:  R 
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Use  Data  From;  Listed  Table 

Output  Devices:  Screen 

Display  Working  Message:  Yes 

Working  Message:  Here  is  the  Requested  Data 


Printer  Port; 

Default 

Page  Break: 

Default 

Prefix  String: 

None 

Suffix  String: 

None 

Setup  Proc. 

None 

Cleanup  Proc: 

None 

Table:  T321 

Report  #:  1 

Renort  Print:  PRN321 

Use  Data  From; 

Listed  Table 

Output  Devices: 

Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message; 

Personal  Information  Card  ... 

Printer  Port: 

Default 

Page  Break: 

Default 

Prefix  String: 

None 

Suffix  String: 

None 

Setup  Proc; 

None 

Cleanup  Proc; 

None 

Table:  T322 

Report  #;  1 

Renort  Print:  PRN322 

Use  Data  From: 

Listed  Table 

Output  Devices. 

Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message: 

Personal  Info  Book/Record  ... 

Printer  Port. 

Default 

Page  Break: 

Default 

Prefix  String: 

None 

Suffix  String; 

None 

Setup  Proc: 

None 

Cleanup  Proc. 

None 
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Table  T324B 
Report  #:  1 


Use  Data  From:  Listed  Table 

Output  Devices:  Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message:  1/2  Crew  Division  System  Report  ... 

Printer  Port:  Default 

Page  Break:  Default 

Prefix  String:  None 

Suffix  String.  None 

Setup  Proc:  None 
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Cleanup  Proc: 


None 


Table:  T324C 
Report  #:  1 

Report  Print:  PRN324C 

Use  Data  From: 

Listed  Table 

Output  Devices: 

Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message: 

Session  Division  Report  ... 

Printer  Port; 

Default 

Page  Break: 

Default 

Prefix  String: 

None 

Suffix  String: 

None 

Setup  Proc; 

None 

Cleanup  Proc; 

None 

Table:  T325A 
Report  #:  1 

Report  Print;  PRN325A 

Use  Data  From: 

Listed  Table 

Output  Devices; 

Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message: 

Alert  Station  Report  ... 

Printer  Port; 

Default 

Page  Break: 

Default 

Prefix  String: 

None 

Suffix  String; 

None 

Setup  Proc; 

None 

Cleanup  Proc; 

None 

Report  Print  PRN325B 

Table:  T325B 
Report  #:  1 

Use  Data  From:  Listed  Table 

Output  Devices:  Screen,  Printer 

Display  Working  Message:  Yes 


137 


Working  Message. 

Special  Station  Report  . 

Printer  Port: 

Default 

Page  Break: 

Default 

Prefix  String: 

None 

Suffix  String. 

None 

Setup  Proc: 

None 

Cleanup  Proc; 

None 

Reoort  Print:  PRN325C 

Table:  T325C 

Report  #:  1 

Use  Data  From; 

Listed  Table 

Output  Devices; 

Screen,  Printer 

Display  Working  Message;  Yes 

Working  Message: 

Abandon  Ship  Station  Report  ... 

Printer  Port: 

Default 

Page  Break. 

Default 

Prefix  String: 

None 

Suffix  String: 

None 

Setup  Proc; 

None 

Cleanup  Proc. 

None 

Reoort  Print:  PRN331 

Table;  T331 

Report  #;  1 

Use  Data  From. 

Listed  Table 

Output  Devices: 

Screen,  Printer 

Display  Working  Message;  Yes 

Working  Message: 

Air  Control  Monthly  Report  ... 

Printer  Port; 

Default 

Page  Break: 

Default 

Prefix  String: 

None 

Suffix  String: 

None 

Setup  Proc. 

None 

Cleanup  Proc: 

None 

Reoort  Print;  PRN332 

Table;  T332 

Report  #:  1 

138 


Use  Data  From: 

Listed  Table 

Output  Devices: 

Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message: 

Officer  Special  Report 

Printer  Port: 

Default 

Page  Break: 

Default 

Prefix  String; 

None 

Suffix  String: 

None 

Setup  Proc: 

None 

Cleanup  Proc: 

None 

Report  Print.  PRN333 

Table;  T333 

Report  #:  1 

Use  Data  From; 

Listed  Table 

Output  Devices: 

Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message: 

Officers'  Monthly  Report  ... 

Printer  Port: 

Default 

Page  Break; 

Default 

Prefix  String: 

None 

Suffix  String: 

None 

Setup  Proc: 

None 

Cleanup  Proc: 

None 

Report  Print;  PRN334 

Table:  T334 

Report  #:  1 

Use  Data  From: 

Listed  Table 

Output  Devices. 

Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message; 

Petty  Officers'  Monthly  Report 

Printer  Port. 

Default 

Page  Break: 

Default 

Prefix  String. 

None 

Suffix  String: 

None 

Setup  Proc; 

None 

Cleanup  Proc: 

None 
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Table:  T335 
Report  #:  1 


Use  Data  From:  Listed  Table 

Output  Devices:  Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message.  Sailors'  Monthly  Report... 

Printer  Port:  Default 

Page  Break.  Default 

Prefix  String:  None 

Suffix  String:  None 

Setup  Proc:  None 

Cleanup  Proc:  None 


Report  Print:  PRN336 


Table:  T336 
Report  #:  1 


Use  Data  From:  Listed  Table 

Output  Devices.  Screen,  Printer 

Display  Working  Message:  Yes 

Working  Message:  Sailors’  Punishment  Monthly  Report... 

Pnnter  Port:  Default 

Page  Break  Default 

Prefix  String:  None 

Suffix  String:  None 

Setup  Proc.  None 

Cleanup  Proc:  None 
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C  PART  THREE:  DOCUMENTATION  OF  CROSS-REFERENCE  MENU 


SPAS  -  Shipboard  Personnel  Administration  System 
Cross  Reference 

Action  Objects  &  Paradox  Objects  in  Use 


Objects  in  the  Menu  &  Object  Tables:  Referenced  bv: 
Object  Type  Object  Name  Object  Type  Object  Name 


Edit  Session 

SNllA 

Multiple  Actions  MAIl 

Edit  Session 

SNUB 

Multiple  Actions  MAJ 1 

Edit  Session 

SNllC 

Multiple  Actions  MAll 

Edit  Session 

SNllD 

Multiple  Actions  MAll 

Edit  Session 

SN12 

Menu 

CFG\SPAS 

Edit  Session 

SN124 

Menu 

CFG\SPAS 

Edit  Session 

SN13 

Menu 

CFGVSPAS 

Edit  Session 

SN141 

Menu 

CFGXSPAS 

Edit  Session 

SN151 

Menu 

CFGXSPAS 

Edit  Session 

SN152 

Menu 

CFGXSPAS 

Edit  Session 

SN1531 

Menu 

CFG\SPAS 

Edit  Session 

SN1532 

Menu 

CFGVSPAS 

Edit  Session 

SN153 

Menu 

CFGXSPAS 

Edit  Session 

SN1541 

Menu 

CFG\SPAS 

Edit  Session 

SN1542 

Menu 

CFGXSPAS 

Edit  Session 

SN1543 

Menu 

CFG\SPAS 

Edit  Session 

SN1551 

Menu 

CFG\SPAS 

Edit  Session 

SN1552 

Menu 

CFG\SPAS 

Edit  Session 

SN1553 

Menu 

CFG\SPAS 

Edit  Session 

SN1561 

Menu 

CFG\SPAS 

Edit  Session 

SN1562 

Menu 

CFGVSPAS 

Edit  Session 

SN1563 

Menu 

CFGXSPAS 

Edit  Session 

SN21 

Menu 

CFG\SPAS 

Edit  Session 

SN22 

Menu 

CFG\SPAS 

Edit  Session 

SN311 

Multiple  Actions  MA3 1 1 

Edit  Session 

SN312 

Multiple  Actions  MA312 

Edit  Session 

SN313 

Multiple  Actions  MA313 

Edit  Session 

SN314 

Multiple  Actions  MA314 

Edit  Session 

SN315 

Multiple  Actions  MA315 

Exit  Paradox 

Menu 

CFGVSPAS 

Form 

AD-HOC  F 

Edit  Session 

SN311 

Edit  Session 

SN312 

Edit  Session 

SN313 

Edit  Session 

SN314 

Edit  Session 

SN315 

Form  AIR-CTRLFl 
Form  DEPENDENFl 


Form  DESCIPLNFl 


Form  FITNESS.Fl 
Form  LEAVE.Fl 
Form  OJT-EVAL.Fl 


Form  PERSDUTYFl 
Form  PERSON.Fl 


Form  PERSTATN.F) 
Form  PROMOTIO.Fl 

Form  REQUESTFl 
Multiple  Actions  MAll 
Multiple  Actions  MAS  1 1 
Multiple  Actions  MAS  12 
Multiple  Actions  MAS  IS 
Multiple  Actions  MASH 
Multiple  Actions  MAS  15 
Multiple  Actions  MAS21 
Multiple  Actions  MAS22 
Multiple  Actions  MAS2S 
Multiple  Actions  MAS24A 
Multiple  Actions  MAS24B 
Multiple  Actions  MAS24C 
Multiple  Actions  MAS25A 
Multiple  Actions  MAS25B 
Multiple  Actions  MAS25C 
Multiple  Actions  MASSl 
Multiple  Actions  MASS2 
Multiple  Actions  MASSS 
Multiple  Actions  MASS4 
Multiple  Actions  MASSS 
Multiple  Actions  MASS6 
Play  a  Script  ADHOCl 
Play  a  Script  ADHOC2 


Edit  Session  SN151 
Edit  Session  SN12 
Edit  Session  SN1541 
Edit  Session  SN1542 
Edit  Session  SN154S 
Edit  Session  SNIS 
Edit  Session  SN1551 
Edit  Session  SN1552 
Edit  Session  SN1553 
Edit  Session  SN124 
Edit  Session  SN22 
Edit  Session  SN14I 
Edit  Session  SN1561 
Edit  Session  SN1562 
Edit  Session  SNI563 
Edit  Session  SNllD 
Edit  Session  SNllA 
Edit  Session  SN1531 
Edit  Session  SN1532 
Edit  Session  SN1533 
Edit  Session  SNllC 
Edit  Session  SNUB 
Edit  Session  SN152 
Edit  Session  SN21 
Menu  CFGXSPAS 
Menu  CFG\SPAS 
Menu  CFG\SPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Menu  CFGNSPAS 
Multiple  Actions  MA3 1 1 
Multiple  Actions  MA312 
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Play  a  Script 

ADHOC3 

Multiple  Actions 

MA313 

Play  a  Script 

ADHOC4 

Multiple  Actions 

MA314 

Play  a  Script 

ADHOC5 

Multiple  Actions 

MA315 

Play  a  Script 

EMPTY 

Multiple  Actions 

MA311 

Multiple  Actions 

MA312 

Multiple  Actions 

MA313 

Multiple  Actions 

MA314 

Multiple  Actions 

MA315 

Play  a  Script 

Q321 

Multiple  Actions 

MA321 

Play  a  Script 

Q322 

Multiple  Actions 

MA322 

Play  a  Script 

Q323 

Multiple  Actions 

MA323 

Play  a  Script 

Q324A 

Multiple  Actions 

MA324A 

Play  a  Script 

Q324B 

Multiple  Actions 

MA324B 

Play  a  Script 

Q324C 

Multiple  Actions 

MA324C 

Play  a  Script 

Q325A 

Multiple  Actions 

MA325A 

Play  a  Script 

Q325B 

Multiple  Actions 

MA325B 

Play  a  Script 

Q325C 

Multiple  Actions 

MA325C 

Play  a  Script 

Q331 

Multiple  Actions 

MA331 

Play  a  Script 

Q332 

Multiple  Actions 

MA332 

riay  a  Script 

Q333 

Multiple  Actions 

MA333 

Play  a  Script 

Q334 

Multiple  Actions 

MA334 

Play  a  Script 

Q335 

Multiple  Actions 

MA335 

Play  a  Script 

Q336 

Multiple  Actions 

MA336 

Procedure 
Quit  to  Paradox 


Application  SPAS 
Menu  CFG\SPAS 


Report 

ANSWER.R 

Report  Print 

PRN311 

Report  Print 

PRN312 

Repon  Print 

PRN313 

Repon  Print 

PRN314 

Report  Print 

PRN315 

Report 

T321.R1 

Report  Print 

PRN321 

Report 

T322.R1 

Report  Print 

PRN322 

Report 

T323.R1 

Report  Print 

PRN323 

Report 

T324A.RI 

Repon  Print 

PRN324A 

Repor. 

r324B.Rl 

Report  Print 

PRN324B 

Report 

T324C.RI 

Report  Print 

PRN324C 

Report 

T325A.R1 

Report  Print 

PRN325A 

Report 

T325B.R] 

Report  Print 

PRN325B 

Report 

T325C.R1 

Report  Print 

PRN325C 

Report 

T331.R1 

Report  Print 

PRN331 

Report 

T332.R1 

Report  Print 

PRN332 

Report 

T333.R1 

Report  Print 

PRN333 

Report 

T334.R1 

Report  Print 

PRN334 

Report 

T335.R1 

Report  Print 

PRN335 

Report 

T336.R1 

Report  Print 

PRN336 

Report  Print  PRN311  Multiple  Actions  MA311 

Report  Print  PRN312  Multiple  Actions  MA3I2 
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Report  Print  PRN313 
Report  Print  PRN314 
Report  Print  PRN3 1 5 
Report  Print  PRN321 
Report  Print  PRN322 
Report  Print  PRN323 
Report  Print  PRN324A 
Report  Print  PRN324B 
Report  Print  PRN324C 
Report  Print  PRN325A 
Report  Print  PRN325B 
Report  Print  PRN325C 
Report  Print  PRN331 
Report  Print  PRN332 
Report  Print  PRN333 
Report  Print  PRN334 
Report  Print  PRN335 
Report  Print  PRN336 
Table  AD-HOC 


Table  AIR-CTRL 
Table  ANSWER 


Table  DEPENDEN 


Table  DESCIPLN 


Table  FITNESS 
Table  LEAVE 
Table  OJT-EVAL 


Table  PERSDUTY 
Table  PERSON 


Multiple  Actions  MA313 
Multiple  Actions  MA314 
Multiple  Actions  MA3 1 5 
Multiple  Actions  MA321 
Multiple  Actions  MA322 
Multiple  Actions  MA323 
Multiple  Actions  MA324A 
Multiple  Actions  MA324B 
Multiple  Actions  MA324C 
Multiple  Actions  MA325A 
Multiple  Actions  MA325B 
Multiple  Act’  IS  MA325C 
Multiple  Act.^  ns  MA331 
Multiple  Actions  MA332 
Multiple  Actions  MA333 
Multiple  Actions  MA334 
Multiple  Actions  MA335 
Multiple  Actions  MA336 
Edit  Session  SN3 1 1 
Edit  Session  SN312 
Edit  Session  SN313 
Edit  Session  SN314 
Edit  Session  SN315 
Edit  Session  SN151 
Report  Print  PRN3 1 1 
Report  Print  PRN312 
Report  Print  PRN313 
Repon  Print  PRN314 
Report  Print  PRN3 1 5 
Edit  Session  SNI2 
Edit  Session  SN1541 
Edit  Session  SN1542 
Edit  Session  SN1543 
Edit  Session  SN13 
Edit  Session  SN155I 
Edit  Session  SN1552 
Edit  Session  SN1553 
Edit  Session  SN124 
Edit  Session  SN22 
Edit  Session  SN141 
Edit  Session  SN1561 
Edit  Session  SN1562 
Edit  Session  SN1563 
Edit  Session  SNllD 
Edit  Session  SNllA 
Edit  Session  SN1531 
Edit  Session  SN1532 
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Table  PERSTATN 
Table  PROMOTIO 

Table  REQUEST 
Table  T321 
Table  T322 
Table  T323 
Table  T324A 
Table  T324B 
Table  T324C 
Table  T325A 
Table  T325B 
Table  T325C 
Table  T331 
Table  T332 
Table  T333 
Table  T334 
Table  T335 
Table  T336 


Edit  Session  SN1533 
Edit  Session  SNllC 
Edit  Session  SNUB 
Edit  Session  SN152 
Edit  Session  SN21 
Report  Print  PRN321 
Report  Print  PRN322 
Report  Print  PRN323 
Report  Print  PRN324A 
Report  Print  PRN324B 
Report  Print  PRN324C 
Report  Print  PRN325A 
Report  Print  PRN325B 
Report  Print  PRN325C 
Report  Print  PRN331 
Report  Print  PRN332 
Report  Print  PRN333 
Report  Print  PRN334 
Report  Print  PRN335 
Report  Print  PRN336 
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APPENDIX  I:  PROCEDURES  FOR  INSTALLING  AND  OPERATING  SPAS 


A.  Installation  Procedure 

To  run  any  Paradox  application,  Paradox  itself  must  be  installed.  To  install  Paradox 
the  user  has  to  run  the  Paradox  installation  program.  Instructions  for  installing  Paradox 
can  be  found  in  Paradox  manuals. 

B.  Setting  up  the  SPAS  application 

After  installing  Paradox  you  need  to  setup  the  SPAS  application.  This  can  be  done 
in  several  ways  The  suggested  method  from  the  DOS  environment  is  described  on  the 
following  page  Your  SPAS  application  disk  includes  all  required  files  and  has  one 
directory  and  two  subdirectories.  Figure  16  shows  how  the  files  are  organized  in  the 
diskette. 


Figure  16:SPAS  application  disk  hierarchy 


From  the  DOS  environment,  insert  the  application  disk  into  the  floppy  drive,  and 
perform  the  following  steps; 

1  Make  sure  that  you  are  at  the  C:\PDOX40>.  (If  you  are  at  the  C:\>,  type  cd 
PDOX40  and  then  hit  enter). 

2.  Type  md  SPAS  (creates  the  SPAS  directory) 

3.  Type  cd  SPAS  (puts  you  in  SPAS  directory  and  displays  the  C:\PDOX40\SP AS> 
prompt) 

4.  Type  md  CFG  (creates  the  CFG  directory) 

5.  Type  md  WORKSHOP  (creates  the  WORKSHOP  directory) 

6  Type  copy  a:\spas\*.*  c:  (copies  the  files  to  hard  disk) 

7  Type  cd  CFG  (puts  you  in  the  CFG  directory  and  displays  the 
C:\PDOX40\SP AS\CFG>  prompt) 

8  Type  copy  a:\spas\cfg\*.*  c:  (copies  the  files  to  hard  disk) 

9  Type  cd..  (you  are  at  the  C:\PDOX40\SPAS>  prompt) 

10  Type  cd  WORKSHOP  (puts  you  in  the  WORKSHOP  directory  and  displays  the 
C  \PDOX40\SPAS\WORKSHOP>  prompt) 

1 1  Type  copy  a:\spas\workshop\*.*  c:  (copies  the  files  to  hard  disk) 

Now  you  have  everything  copied  on  your  hard  disk  drive,  and  your  application  is 
ready  to  run  You  can  start  running  Paradox  by  typing  "paradox"  at  the 
C:\PDOX40\SPAS>  prompt.  Figure  17  shows  how  your  screen  will  look  like 
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Figure  17;  Paradox  screen 


C.  Using  the  SPAS  24)plication 

To  run  the  SPAS  application  in  the  Paradox  environment,  you  have  to  select  the 
application  from  the  pull-down  menu  bar.  Using  the  mouse,  click  on  the  top  left  most 
field  of  the  pull-down  menu  bar  (indicated  by  three  horizontal  lines),  then  click  on 
"Utilities",  and  then  click  on  "Workshop".  The  working  desktop  now  is  the  Paradox 
workshop.  On  the  new  desktop,  click  on  "Application",  then  on  "Directory",  type 
c:\pdox40\spas  and  hit  enter, or  click  on  OK.  Now  you  are  at  the  application  workspace. 
Click  again  on  "ParadoxEdit",  "Scripts"  and  select  "SPAS"  from  the  scripts  list.  Finally 
click  on  "Play"  and  the  SPAS  application  will  be  executed  showing  a  screen  that  looks 
like  figure  18. 
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Figure  18:  SPAS  screen 


1.  Main  menus 

The  application  has  four  main  pull-down  menus.  Figure  18  shows  the  main 
menus  named  'PERSONNEL  SUBSYSTEM",  "REQUEST  SUBSYSTEM",  "REPORT 
SUBSYSTEM",  and  "EXIT".  Each  menu  has  submenus  which  in  turn  may  have 
submenus.  The  function  of  each  menu  is  self  descriptive.  For  more  details  refer  to 
Appendix  E 
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2.  Help  screens 

Help  screens  are  included  in  SPAS  and  are  designed  to  help  the  user  follow 
the  right  steps  for  each  procedure.  In  this  way  the  user  can  respond  correctly  to  data 
entry  and  updates  and  eliminate  potential  mistakes. 

3.  Printing  outputs 

After  performing  a  report  operation  from  the  report  subsystem,  there  is  a  dialog  box 
asking  whether  to  print  the  results  onto  the  screen,  or  to  the  printer.  Choose  the  desired 
output  media  from  this  menu. 
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